In a message dated 11/1/00 5:28:36 AM, [EMAIL PROTECTED] writes:
>OK, you start ;-) While I think there'll be a tendency to design a
>camel here (one person just wants support for binary data, another
>wants standard access to engine internals like the SC toolbox, while
>a third wants to build a whole plug-in architecture), starting out
>with some pie-in-the-sky ideas doesn't seem like a bad idea to me.
>Let's hear 'em.
I might as well get saying that SuperCard already has all of the above out of
the way first. Obviously this reduces somewhat my incentive to help invent a
new parallel API and then do a bunch of work to implement it, especially if
the design is likely to end up being (as Scott wisely suggests) some sort of
camel. If resources were available in infinite supply of course I'd be happy
to, but M$ we ain't.
I don't want this to turn into a commercial or a pissing contest, but let me
review briefly the current state of affairs vis-a-vis extensibility in
SuperCard:
- Parameters can be passed by reference (allowing for bidirectional transfer
of binary data). This mechanism is by no means perfect (whoever wrote it
neglected to allow externals a way to determine whether params came by ref or
value, so you have to just trust the scripter) but if everyone plays by the
rules it does work just fine.
- As you know here on the Mac side we've no need for a parameter length
attribute.
- With the Internals Toolbox (currently over 160 callbacks, available with
full source at no extra charge) we offer external authors low-level access to
all SuperCard's important internal data structures and internal routines.
- We offer a memory-resident plug-in API (XRTNs) through which externals can
own their own windows and register for first crack at (as of this writing)
approximately three dozen internal or OS-level events, access all the same
internal goodies as XCMDs, and even patch or replace any important internal
SuperCard routine with their own version. Starting with our next major
release this API will likely permit definition of new embedded object classes
for fields as well.
With the impending advent of OSX (and the late binding of Objective C) the
thing I'm more interested in right now is devising a robust plug-in object
architecture for our Cocoa port which will allow user-defined objects to
control not only their appearance and behavior but also their xtalk interface.
All that said, I'm not averse to discussing future options. Just keep in mind
that you're trying to sell me something I've already got more of than you're
probably willing to swallow yourself...
-Mark
