Hi,
it appears our discussions about extending the XCMD protocol have pretty
much died down ? I guess most of us have voiced their concerns and desires,
but since many of us are currently not at a stage in their xTalk projects
to implement XCMDs, maybe we could try a different approach?
Since Scott (i.e. the MetaCard folks) are apparently planning on
implementing a new XCMD interface, wouldn't it be nice if they just came up
with a design how they would like it, building on what was discussed here
so far, and then we can comment if anything there is incompatible with the
way other xTalks work.
Is that OK with you, Scott? If the protocol is designed in an open
fashion, it would be fairly easy to later on add any missing features (but
please also let them pass through this list) that the MetaCard crew didn't
want to tackle at the time. The important matter isn't that every host
supports the entire set of callbacks, rather it is more important that
there aren't five APIs in every host application that allow doing the very
same thing but require special code. The xTalk market will profit much more
from devising a common platform to enlarge the target audience for XCMD
developers than it would from trying to achieve monopolies.
One more thing to think about: We might want to design the APIs in a way
that they can also be implemented by means of an XCMD or XRTN. This
shouldn't be a problem, but it might help in making this new protocol
compatible with as many applications that understand the old XCMD protocol
as possible if we didn't do anything that makes this impossible. Of course,
this compatibility layer will not be able to provide handling of NULL
characters properly (except on Macintosh), but many externals probably
don't even need such features.
Cheers,
-- M. Uli Kusterer
------------------------------------------------------------
http://www.weblayout.com/witness
'The Witnesses of TeachText are everywhere...'
The future of programming: http://freecard.sourceforge.net
