On Wed, 1 Nov 2000, M. Uli Kusterer wrote:
> >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.
>
> Scott,
>
> welllllll....
>
> seriously, my pie-in-the-sky ideas would be (less obvious/most wanted first):
>
> 1) passing binary data as parameters
> 2) callbacks to handle associative arrays or similar keyed data structures
> (as parameters, return value etc.)
The basics.
> 3) callbacks to manipulate objects, i.e. GetProperty()/SetProperty(),
> access and creation to/of user properties
I'm of two minds about this. On the one hand, if you're going to
provide functions to get and set field contents, why not ones for
properties. On the other, since you've got to go through a lookup or
two to map a property name string to a property, there's not a huge
benefit here over just building a string and executing it via
"SendCardMessage" or something. Adding stuff just to add stuff is not
a great design philosophy.
> 4) Everything HyperCard has for XCMDs, except maybe the xWindow stuff and
> debugger
Most of the rest (the 2.0 extensions) only apply to Mac-specific stuff
like image formats and Mac ToolBox data structures. But if there are
commonly used functions that don't fall into these categories, or that
do but can be generalized into a cross-platform form, we definitely
should consider including them. Any XCMD developers out there got a
favorite HC 2.0 callback?
> 5) Persistent externals that can be used for platform-specific hacks
> (callbacks etc.)
Persistence is just an implementation issue, not an API issue. We
could just specify one or the other, but it sounds like what you're
proposing is something like allowing the external to spawn a thread
that can call back to the engine at any time. There are pretty major
issues associated with that, like requiring support for reentrancy of
all engine features. We've already solved most of these in MetaCard
(I've seen Windows externals that do this), but there's a big gap
between having some things work and having everything work. We may
just want to specify that things like "SendCardMessage()" can be
called from threads.
> Of course, if you want PIE-IN-THE-SKY, I'd add
>
> 6) Adding custom part types
OpenDoc? ;-)
> 7) Fully customizable english-like syntax for XCMD and XFCN calls
This is a whole 'nother can of worms, and it affects writing xTalk
handlers too. I get a headache every time I start thinking about how
one would go about adding the ability to include support for
"syntactic sugar" in user-defined handlers without giving up the
ability to have expressions evaluated before they're passed as
parameters:
myaddcommand 3 to it -- the "to" here is going to cause problems!
> 8) cross-platform drawing and windowing callbacks, and everything else
> like file management, mouse tracking ...
Embedded MetaCard has hooks into the main event loop that allow
external code to do pretty much anything it wants to before the engine
even processes the events. But this is only supported on UNIX. We
may want to consider standardizing some of this stuff too, although
there are pretty serious cross-platform issues here (e.g., you don't
want to be trying to generate a cross-platform equivalent of the event
structure on each platform and packing and unpacking all the bits
going in out of the external).
> Then again, I probably wouldn't want to be the one to implement the latter :-T
Hmm, I was thinking you were going to be showing us the way ;-)
Scott
> Cheers,
> -- M. Uli Kusterer
>
> ------------------------------------------------------------
> http://www.weblayout.com/witness
> 'The Witnesses of TeachText are everywhere...'
> The future of programming: http://freecard.sourceforge.net
>
>
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
