> MP0werd : We create an opencard engine, an xTalk interpreter that can
> be #included into any project, without any hassle.
Alain : Excellent idea. We should make our system inter-operate with as
many other systems as possible.
> MP0werd : We shall also have another library, a library of essential
> commands, like BEEP, PLAY, SEND, etc.
Alain : We could do like NextStep. Provide a powerful shell that
provides hooks into each and every technology we deem worth pursuing.
> MP0werd : The only things that I would consider non-essential are
> commands that manipulate the environment outside of opencard, like
> quicktime (although speech and sound manager support should be
> included), and games sprockets, etc.
Alain : Do we create a mac-specific version of OpenCard, or do we try
to develop something that is inherently multi-platform ?
> MP0werd : We want to have a good scripting base to make our language
> attractive to people who just want to have some MACRO functionality in
> their programs, or just want to make it look cooler.
Alain : I agree.
> MP0werd : B) The commands like GO CARD should activate another
> routine in a different
> library consisting of routines that need to be changed to bind xTalk
> with the program. This would be anything to do with i/o, like file
> handling and windows and cards and playing sounds.
MP0werd : Good principle.
> MP0werd : These should have already-made programming to serve as an
> example, and in case the programmer doesn't want to bother with a
> particular aspect (ie, the sound manipulation routines could be ok by
> the programmer).
Alain : I agree. I would furthermore provide them with something
similar to HyperCard's buttonTasks, but with many more prefabricated
functionalities, and the possibly of adding new ones. I never understood
why Apple did not provide for us users to create new ButtonTasks.
> MP0werd : C) The engine should be able to communicate with other
> copies of the engine, even over networking environment if desired.
> This would allow programs to work together.
Alain : I like this. Xavier and me would also like to develop this type
of "Across-the-Web" interaction, to create sophisticated
distributed-programming systems (agents), by exploiting AppleShare IP
(for now). We haven't quite got around to it yet though. I haven't found
the time.
> MP0werd : D) The engine should be small. S M A L L. This does not
> include the commands library, but most command should be expendable,
> and you should be able to
> delete them in order to free up room.
Alain : Reminds me of the slew of posts on the HC list concerning how
to slim down HyperCard standalones. Small is definitely Beautiful. It
would indeed be nice if our standalone creator could import just what it
needs to make the smallest standalone possible.
> MP0werd : E) WE decide the syntax of all additions and modifications
> to our engine. All
> programmers using our engine must submit a form with details on any
> changes made, and wait for approval of us. We reserve the right to
> standardize the syntax, ...
Alain : OK. But we will read, consider, and act upon each and every
suggestion posted to us. As opposed to .... you know who.
> MP0werd : ... so JAVA OpenTalk does QT the same way as OpenDoc
> OpenTalk.
Alain : OpenDoc OpenTalk ... That would be a marriage made in heaven.
Do you think that it is even remotely possible that we could convince
Apple to release OpenDoc ? It was Steved some time ago. They aren't
using it, except for the ASIP manager.
> MP0werd : This ensures portability, there should have to be no
> modifications to a script to make it work on other versions of the
> engine
Alain : Portability is very important.
