At 11:12 AM 1/26/2003 -0200, you wrote:




I've been following the whole discussion of interoperability with some
interest. The newest version of my own software suite has just entered beta
testing, so these issues have been on my mind lately. Sorry for the
verbosity, but I've got a grab bag of a couple things I'd like to vent on.

Any integration that Guide can do with other software would be welcome -
currently, Guide does not play with others (it isn't that it doesn't play
well with others - it simply doesn't PLAY with others, period). At the
moment, the only way I see this being possible in any sort of a broad way
is through ASCOM-like behaviour. Users lobbying for this ought to be made
aware that implementing this broadly in Guide would be VERY non-trivial. To
provide external access to every guide menu and preference item could
easily take Bill a year or more of 100% dedicated work on that matter alone.

Obviously what's being complicated in real life is some partial effort
released incrementally. This would be nice, and adding support for ASCOM
telescope drivers would be a very desirable first step for many users and
of no consequence to the rest. There's a number of different ways to go
about implementing support for component drivers, as Bill and I have
discussed, and doing this should not be too terribly painful or time
consuming. It would give Guide the ability to operate in multiplex contexts
that currently depend solely on COM port arbitration. This, along with
expanded support for additional kinds of telescopes, would be a plus.

Com port arbitration, as we have seen, is liked by some (Bill) and disliked
by others (Richard). Frankly, I hate it. It tends to be collisional and
apps tend to throw errors immediately rather than do some retries for a few
seconds before giving up. Guide is well-behaved here; it is other software
that isn't. Because you can't count on the other software being
well-written, IMO it is not desirable to depend on it. By comparison,
multiplexing a single driver between multiple programs is sheer heaven on
earth.

I note several comments in this thread that seem ignorant of what ASCOM is
and what sort of choices this means for Bill and for Guide users. ASCOM is
a shared component interface standard, nothing more. It happens to be a
very good standard that works very well.

The choice of implementing ASCOM telescope drivers is not an either-or
choice as several have made it out to be. Guide can (and should) support
both its own proprietary internal drivers as well as freeware ASCOM
telescope drivers from other sources, and Bill mentioned this was his
intent, I believe. After adding ASCOM telescope support, to the user the
choices would be the current list of telescopes, plus "ASCOM telescope."
The addition would change nothing for legacy users, and lobbying against
ASCOM telescope support is exactly the same as saying "we want our
telescopes to be supported but we want NO support for the telescopes owned
by those other guys." Lets have some respect for other Guide users whose
telescopes aren't supported, ok? Is it really in your (users') best
interest to try to restrict Guide's marketability? What is gained by saying
"I have a Meade LX-200 but I do NOT want Gemini telescopes to be supported
in Guide" (for example)? Exactly nothing, and much is lost.

There has also been an assumption that ASCOM drivers come from a particular
company - perhaps one called ASCOM. This isn't the case. ASCOM telescope
drivers come from a variety of different vendors. Sometimes the driver is
written by the scope maker. Sometimes it is written by a user. Sometimes it
is written by a software developer who wants to support a given scope (this
is, I think, the way 100% of Guide's current scope drivers were written).
In all cases, the author has released the driver as freeware and it is
distributed with other drivers in an ASCOM platform.

Richard said "It sure has problems in Starry Night Pro 4.x" but this is not
correct. I've used Starry Night Pro 4.x in a couple dozens contexts and the
ASCOM telescope drivers work VERY nicely with it. What does not always work
well is a telescope driver written by a third party that is trying to
control a telescope with some incompatibilities. (This is why there is more
than one ASCOM telescope driver for certain types of telescopes - a couple
vendors give the software developers a moving firmware target that needs to
be hit.) So when that happens, then obviously it would be advisable to use
a different driver. I make my living (such as it is) getting telescopes to
operate unattended for days or weeks on end using ASCOM telescope drivers
and other software. If these drivers didn't work REALLY well and EXTREMELY
reliably, we'd know all about it, and if it persisted we'd be out of
business. In fact, the drivers work on average a lot better and more
reliably than most of the drivers shipped with commercial star charting
software of various brands. And I hate to say this, but for certain
telescopes this definitely includes Guide's drivers.

The ASCOM telescope driver standard and collection of drivers do not
currently support any digital setting circles as far as I am aware.
Although it could be done, it would probably be better to use an ASCOM DSC
driver instead. The ASCOM telescope standard presupposes that you can issue
the telescope a slew command, i.e., that the telescope is a read-write
device. The basic concept of a DSC is read-only (though some DSC devices
allow "write" operations in the form of sync'ing, changing modes, etc,
these do not affect the telescope itself). If someone wanted to write an
ASCOM DSC driver, doing so would be trivially simple - download the ASCOM
Platform, install it to include developer's tools, and fill in the
necessary blanks in the template code. Lack of DSC support is one reason
why you wouldn't want to rely on ASCOM telescope drivers solely - but it
would be a silly reason to avoid using ASCOM telescope drivers. (And I bet
Bill could write an ASCOM DSC driver using the Platform template much
faster than he could write a DSC driver in the old Guide manner.)



--
Jeff Medkeff
Sierra Vista, Arizona
http://www.roboticobservatory.com/jeff/