Re: OSA modernization and scope

Before you go too far down this road, you might want to check this out.

http://www.w3.org/TR/2008/WD-exi-20080919/

It's highly likely that the various scripting languages developers will adopt this protocol on their own, so all Apple would have to do is create a tool sort of like the "Carbon Dater" utility to help software vendors convert their existing AppleScript support to the new standards-based API. It would be a lot less work for them and they wouldn't need to waste their time trying to gain support for a new standard or herd cats in the various scripting language worlds to support their efforts. If they wait a year or so, the cats will herd themselves and Apple can just worry about the OS X implementation and conversion stuff.

If you are itching to get in on the action, you could probably work up a demo that uses EXI to communicate between a script (Perl, Python, Ruby etc) and an Adobe app using one of their free SDKs (available here: http://www.adobe.com/devnet/sdks.html)

Really the main advantages AppleScript had going for it was the standardized packaging of data and a wire / dispatch mechanism. EXI solves the protocol, sockets and P2P solve the mechanism.

If you want to nudge Apple towards a new, OSA architecture, EXI (or something like it) seems like the way to go.

On Dec 26, 2008, at 10:00 PM, Philip Aker wrote:

On 2008-12-26, at 16:10:37, Joshua Juran wrote:

Fortunately, Apple has already been shipping an open scripting architecture for several years, which is multiplatform and has enormous developer buy-in.  It's called Unix.

We're also talking about "native" applets, droplets, folder actions, mail rules, Perl Studio, Lua Studio, etc. without the hassle that it takes to map the whole freakin' Cocoa.framework into language X.

If you want to attract people who aren't Mac developers, consider designing a wire protocol that anyone can implement.  Let applications and scripts communicate over pipes or sockets, which all major scripting languages support.

On Mac OS X, methinks it's mach ports. On anything else, it will probably be variants on the preprocessor conditional below.

typedef struct {

  CFIndex version;

  void * info;

  const void *(*retain)(const void *info);

  void (*release)(const void *info);

  CFStringRef (*copyDescription)(const void *info);

  Boolean (*equal)(const void *info1, const void *info2);

  CFHashCode (*hash)(const void *info);

#if defined(__MACH__)

  mach_port_t (*getPort)(void *info);

  void * (*perform)(void *msg, CFIndex size, CFAllocatorRef allocator, void *info);

#else

  HANDLE (*getPort)(void *info);

  void (*perform)(void *info);

#endif

} CFRunLoopSourceContext1;

Here are my key questions:  Is it available as free software on Linux?

That's why we're suggesting CoreFoundation level.

How would it work with Parrot?

"The goal of the Parrot virtual machine is to host client languages, and allow interoperation between them."

Different goals I think. Definitely not a virtual machine. Interoperability to the extent to which each OSA language can support AppleEvents or deal with another language's text result to an 'exec' call. Due to the groundbreaking work done on sdefs, I'd be inclined to think that transferrable objects would be the least overall hassle if expressed in XML but an alternate llvm format could be worth looking into. Each language would have to provide it's own translators for these cases though (perhaps with the aid of built-in facilities for the basic types).

Is it *really* free, or just another lock-in API?

That would be Apple's call. What I think would be best is if the OSA Team could aim for an international standard by a contribution to the existing open source CoreFoundation.