On Wed, 1 Nov 2000 [EMAIL PROTECTED] wrote:
>
> 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.
Is this API documented publicly someplace? It would be good to be
able to have this group be able to look it over with an eye to
providing compatibility wherever possible...
> - As you know here on the Mac side we've no need for a parameter length
> attribute.
I assume you mean via GetHandleSize(). This is a non-starter in a
cross-platform API. Not only is the concept of Handles alien to
non-MacOS developers, it's pretty much obsolete even on that platform
due to poor performance and incompatibility with things like the "new"
operator in C++.
> - 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.
A list of these would be useful to have. My hunch would be that most
of these are MacOS specific (e.g., access to a field's TextEdit
resource, or pointers to windows/pixmaps/resources, etc.) and so would
be of limited use in a cross-platform API. But still, it'd be good to
know what's available and even better if developers using this API
could chime in with the features of it that they find most useful.
> - 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.
I agree that adding support for patching the main event loop would be
useful. But what are "internal events"?
> 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.
This is certainly a related problem, but a little stickier one. While
support for Cocoa objects would be nice, my personal opinion is that a
platform specific API that requires features of a relatively obscure
language isn't going to have much appeal outside a very small group of
developers (and most of those are probably former NeXTStep
developers). Bring back OpenDoc!
> 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...
If you can digest it down to what would work cross-platform, it may be
just the list we need...
Scott
> -Mark
>
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
