Drivers, Upgrades and SW design (was Re: Dedicated Z-wave sites?)

["Robert Green" <ROBERT_GREEN1963@xxxxxxxxx>]

"Dean Roddey" <droddey@xxxxxxxxxxxxxxxx> wrote in message
news:tZIgh.31398$wP1.14116@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> "Robert Green" <ROBERT_GREEN1963@xxxxxxxxx> wrote in message
> news:_s2dnf4eBMnszh7YnZ2dnUVZ_ua3nZ2d@xxxxxxxxxx
> > You don't do much gaming, do you?  You can get sometimes find a driver
> > per week at some of the high end video card support sites.  As more
feedback
> > and problem reports arrive, the fixes soon follow.  The same is true for
> > BIOS's in any new motherboard.  You can see them issued once a month, if
not
> > once a week, after a new board is released.  Some of these fixes are not
minor
> > cosmetic polish, either.

> No, I don't. And we are talking about automation, not gaming, so I'm not
> sure what the relevance is.

Easy, dude!  We *were* talking about PCs and the things that make them stop
working in *general* or at least one of us was!  (-:  I'm afraid you're
taking my
comments as slams against CQ, and they're certainly NOT meant to be.  Along
those more general lines, we were discussing driver problems and whether a
typical end user had any way to tell whether an HA item he had purchased
came with reliable drivers or "junk" drivers.  I made that point because
some of the buggiest, crappiest drivers and application software I have ever
come across came from big name companies like Nikon, Panasonic and Sony.

As for gaming issues, didn't that signal we might *not* be talking about CQ
exclusively?  It would seem logical, though, that you might have CQ users
that want to use CQ to be able to switch their game output from the PC
screen to a large plasma screen and back.  Might that not require talking to
a video driver somewhere in the chain to control whatever's rendering the
images for the screen?

My experience is that a Windows application program can NOT really isolate
itself from drivers and code provided by others.  This is an issue I find
particularly relevant to HA and HT automation programs, simply because of
the range of HW (from a *very* wide variety of manufacturers) that such
programs are expected to support. From my perspective, HA and HT are perhaps
among the most HW-centric applications on the planet.

Why am I "stuck" on this issue of drivers?  We alluded to HomeSeer, if you
recall, and their decision to begin offering "plug ins" for an extra fee.
There was a lot of discussion some time ago about how that decision might
have affected the overall quality of the product.  While it's clearly only a
guess, one reason they might have chosen to use third party plug-ins so was
the sheer magnitude of the problem. There are so many devices needing "plug
ins" or "drivers" (or whatever label one chooses for the SW that
communicates among the application, the OS and the HW) that it's easy to see
that the man doing the core programming might have trouble doing it all.

My admittedly faulty memory seems to recall that CQ did not follow that
plug-in model early on but if I'm interpreting your help forum correctly,
you also seem to have other people writing interfaces between HW and CQ, so
the question seems pretty germane to me.  I'm not certain, but it seems from
this thread:

http://www.charmedquark.com/vb_forum/showthread.php?t=2768&page=2

and this one:

http://www.charmedquark.com/vb_forum/showthread.php?t=2294&highlight=drivers

that other people are writing drivers for CQ, too, or am I misreading that?
If so, how does your schema differ from HomeSeer's use of plug-ins?

(The first above thread also tangentially makes a point I was making
earlier.  If you're
very good at what you do, it won't be long before you're bought out, just
the way
Slim Devices was bought by Logitech, or forced out - we may never know the
details.)

HomeSeer's use of plug-ins may have quite profound implications for CQ,
which seems to be at least a few years and X number of users behind HomeSeer
on the success curve.  As you're painfully aware, the small SW startup guy
has to wear nearly every hat:  accountant, coder, marketer, secretary,
documentor, tech support guy, mail room worker and more.

That's a *lot* of work.

Much of it can't easily be farmed out to others, even when the revenue
stream permits because it's all so dependent on individual knowledge.  All
that you know about the HA field, about your particular program, about your
particular SW techniques, about your clients and so much more does not
transfer easily out of your head and into an assistant's.  That's the
age-old "keyman" problem I alluded to.

After reading through CQ's website and message base, I'm convinced that
you've taken a lot more steps since last I looked to insure that you've got
some assistance that's very well versed in many aspects of your business.
That's very good and very rare in startups.  CQ seems to have become far
more of a group effort than it was the last time I looked, at least a year
or so ago. Keyman issues have killed SW and HW projects both large and small
so it's good to see you've addressed the issue more thoroughly than most.
See, I'm not ALL negative, ALL the time. (-"

Part of my dubious attitude comes from starting out learning linear coding
techniques and morphing through OOP.  I'm still not certain that OOP has
produced all the benefits
that it promised although I'll grudgingly admit it has brought some.  But
who's to say what happened to Fortran won't happen to object oriented
platforms five or ten years from now?  There's a revolution coming in
multiple CPU motherboards that's going to require an OS very different from
anything the current Windows platform can deliver.  A media-savvy home
automation application program would seem to me something that would very
much benefit from having multiple CPUs to handle decoding multiple video and
audio streams.

> > It may well be that in your corner of the world you don't see driver
> > issues but I see them continuously.  As Dennis B. pointed out, the
> > arrival of Vista is going to seriously alter the driver landscape.
Let's
> > just chalk this disagreement up to our differing experience  regarding
> > drivers.  Let's, for the moment, forget that the author of NOOKS
> > reported drivers were at fault in 85% of all system crashes and that
> > 5% of all Windows machines have to be rebooted daily.

> The differences he pointed out was NON-AVAILABILITY of drivers for old
> hardware, nothing to do with quality.

Dennis talked about that but he also talked about the profound design
changes in Vista that are going to seriously alter the way drivers are
written and how they work. Vista represents such a change in a number of
areas that even MS, the *authors* of the OS, couldn't get the new data-based
file system working correctly in time for the initial release.

Forgive my skepticism, but even if you "roll your own" and avoid tight
coupling to the OS by reducing your use of system calls, isolating an
application from an OS is *very* tricky business.  I'd liken it making sure
the plumbing and electricity in the third floor of a house were working
correctly even if someone remodeled and rewired and re-plumbed the entire
first floor.  The OS is the level you have to get through to get access to
the HW unless something's changed quite profoundly since I studied the 7
layer OSI model of computing many, many core dumps ago.  Physical, Data
Link, Network, Transport, Session, Presentation & Application (I got 6 out
of 7 correct from 20+ year old synapses!)

http://www.webopedia.com/quick_ref/OSI_Layers.asp

Correct me, please, if I am wrong, Dean, but I was under the impression that
someone (most likely you) has to personally write a driver for each and
every piece of HW that CQ supports?  Isn't that task as limitless as the
amount of HA and HT devices that a user might be expected to control?
Doesn't it also involve making sure HW upgrades in devices that you control
are reviewed to make sure they still react correctly to commands?  I stopped
buying Sony auxiliary control equipment because they could not standardize
across model lines.  It was in a constant state of chaos. According to this
site:

http://www.brian-patti.com/s-link/

"Sony has chosen to provide very little support for S-Link users or
developers. An official site devoted to S-Link/VisionTouch developers was
closed in April, 1997; since then, Sony has limited support to those
enrolled in its professional developer program (which costs $5000 plus
royalties)."

I imagine things have improved only slightly. (-:

<stuff snipped>

> > Anyone working with more than a home installation of Windows knows how
> > easy it is for a Windows system to grind to a halt for any number of
> > reasons. We both know, or at least I hope we do - me from bitter
experience
> > and you from writing drivers both to spec and to actual hardware in
hand -
> > you can research something to bloody death but the rubber hits the road
> > when you install it.  With the outrageous variety of HW and SW available
> > on the PC

> I'm sorry, but I don't see these problems.

Wow.  I am impressed.  You've never ordered something you've researched that
says it works with "X" configuration only to find out it didn't?  You never
reviewed a specification document that failed to conform to the actual HW in
hand?  I see discussions about just such documentation deviations frequently
here in CHA and elsewhere.

I'm glad you report you're untroubled by such things.  I can't help noting
that reading through your support forum about the problems supporting
I-Tunes and I-Pods "gives me pause" as the Bard might say.  How do you
successfully put a wrapper around something that requires login,
authentication and DRM control?  How do you talk to a device where the maker
has not revealed the internal protocols?  Those seem like gnarly problems to
me!

When CD-recorders hit the market there were waves and waves of
incompatibility problems, from the low-level firmware in drive controllers
to the recorders themselves to the recording software to the very blank
disks themselves.  For self-education, I just typed "Charmed Quark Problem"
without the word driver into Google and the very first message I came across
appears to be driver related.  Simon from Surbiton, England had a Zoomplayer
opening problem:

http://www.charmedquark.com/vb_forum/showthread.php?t=3035&highlight=instanc
es

---------------------------------------------------------------------

Hullo,

I have three instances of ZP, one for movies and two for music.
There are auto opening actions on the relevant templates.

If I go movies, music, all three open as they should.
If I go music, movies, the two for music open correctly, but the movies one
doesnt.

I dont get an error being shown on the app server, and if I enable action
trace I get a Result=Success.

I dont want just to remove all the drivers for ZP and the app server without
trying to figure out what might be causing it.

Any ideas please?

-------------------------------------------------------

Part of your one paragraph reply was: "are the CQC drivers correctly
installed?"

That would at least lend *some* slight support to my contention that no
software is immune from driver issues.  I believe, based on experience, that
driver issues are particularly troublesome in SW that controls the vast
amount of disparate HW.  Loads of very different HW from many manufacturers
seems to be the norm in home theater, home automation and home security.
I'm not trying to be a "nudge" here, I just can't help meeting your claims
that you've insulated yourself from the things that trouble so many other
software applications with a healthy dose of skepticism.  When someone in a
HW-centric field says they have no driver problems, it makes me want to
learn how that's possible because it's so far out of my direct experience
with such SW.

Speaking of drivers, in searching through the CQ support forums, I found
what seemed to be an inability to deal with a customer's pre-existing MP3
library.  Did I read that correctly?  Is CQ, with its heavy emphasis on home
theater, unable to import tagged MP3's correctly into its media repository?