Scott, IncWell folks, Gain folks, everybody,
to make sure we have some starting code upon which develkopers can build,
I have decided to begin writing some starting code for a new cross-platform
XCMD protocol. To distinguish it from traditional HyperCard/SuperCard XCMDs
and MetaCard's external command mechanism, I'll call it "Featz" for now.
As promised, I will offer my thoughts here on this list so all xTalk
programs can work out a common standard, which ought to make sure the user
base is large enough for many plug-ins to be developed. I WELCOME ANY
FEEDBACK you can provide, since I am really serious about making this an
affordable standard for every host application while making sure it is up
to par with all the features modern xTalks have and I want it to provide
source-code compatibility between platforms to a decent degree.
Here's what I have come up with so far:
-> The main container for Featz externals will be a DLL ("shared library")
This option has become viable since AFAIK most modern OSs now support some
kind of "file bundle" which will perfectly hide the dozen or so DLLs next
to the application. Also, installation will be a matter of dropping a file
in a folder and will no longer require any special editors (like some
resource mover).
-> Featz callbacks will be modeled after HyperCard's XCMD protocol but
will use modern linking machanisms (the xCard application will export them
as if it was a DLL) instead of calling entry points with a selector. Here I
need more information from people who have more cross-platform experience
than I have to tell me in case this is a Mac-only thing.
-> Things like the XCmdBlockPtr will be replaced through an opaque "XCMD
reference" which may be a pointer to an internal object of the host
application and will be slimmed down since it won't need stuff like the
parameter array for callbacks anymore. This reference will be passed to
accessor functions to get at things like the parameters passed to the XCMDs.
-> There will be callbacks for array access (also with opaque references
so the host can implement these any way they like and MC don't have to
expose their precious hashing code).
-> Callbacks that manipulate objects will also use opaque references and
there will be special callbacks to manipulate properties and user
properties and to iterate through objects, properties and a field's style
information in a cross-platform manner.
-> Featz externals can request to "stay around" to allow things like
installing system-specific callbacks.
-> About this one I'm not sure: Should we provide a new way to pass around
parameters? We will definitely have to stop passing parameters as C strings
and instead use long-counted strings to allow passing binary data with NULL
characters in it, but should we also allow data types? In that case we'd
have callbacks to get parameters as booleans, c-strings, pascal strings,
raw data, longs, doubles etc. and to set the result in these formats. There
would also need to be a callback to determine the best (="natural") data
type of a parameter. This would also ease adding support for references
since we could provide a callback to modify parameters if they are
references.
This is of course just the tip of the iceberg, but it's a starting point.
Once we have agreed on this I'd create a simple Mac-implementation with an
example external and you could have a look at it and give me feedback. Then
I'll throw it away and write a new one until we have something that we all
can live with.
Cheers,
-- M. Uli Kusterer
------------------------------------------------------------
http://www.weblayout.com/witness
'The Witnesses of TeachText are everywhere...'
