All contributions are welcome. I'm trying to highlight current issues
and/or upgrade direction for OSA components in the hopes it will be
valuable input for the OSA Team at Apple.
To summarise various problems I can see with OSA:
- OSA API works adequately as an AppleScript API. It has completely
failed to deliver successful plug-ins for other languages, partly due
to its technical shortcomings, partly due to lack of promotion and
support by Apple, partly due to lack of interest and/or enthusiasm
from third-party language developers.
- OSA API is arcane, archaic, and inadequately documented.
- OSA API has several design flaws that make it unnecessarily complex
or limited, e.g. ability to instantiate multiple component instances,
failure to distinguish between scripts and their result values, script
error reporting done at component ('global') level instead of per-script
- OSA API does not adequately cater to the needs of most other
languages, e.g. by providing built-in support for hosting interpreters
out of process, not shackling them to Apple events (which are also a
pain in the butt to work with), and making it easy to expose alternate
APIs (e.g. an ObjC API for use by PyObjC/RubyCocoa/etc.)
- OSA API idioms and implementation all derive from pre-OS X days and
not a good match with CoreFoundation/Foundation idioms and
implementation: Component Manager vs CFBundle; OSType vs string-based
keys; script IDs vs ADTs/instances; explicit selectors and DIY
dispatch vs automagical binding, KVC, etc.
- Other than Philip, who is somewhat old-school, I can't think of
anyone who really likes it. And if you can't get a good swathe of
developers enthused about a technology, it really doesn't matter what
its technical merits or demerits are: without users, it isn't worth
squat.
- Lousy name.
It is a waste of time trying to 'improve' the existing OSA API. It is
built on a has-been foundation (Component Manager), using outdated
concepts, with various design flaws baked in to varying degrees of
immovability, and sucks for working with any language not already
called "AppleScript".
OSA works well enough for its primary task, which is to provide a
programmatic interface to AppleScript. Messing with it now may degrade
that particular experience, and still won't make the OSA API a good or
popular foundation for advancing the 'open scripting' concept.
We need a new API, designed from the ground as a CoreFoundation and
Foundation technology, that genuinely caters to the needs of the many
different scripting languages, application APIs, and application
developers out there today. Rigourously specced, properly documented,
promoted and supported, with plenty of shiny to attract language and
application developers who have already written off OSA. Otherwise we
are going to see more fragmentation, more balkanisation, as
application developers increasingly resort to embedding their own
interpreters.
There is huge potential in the core attachability concept - you only
need look at something like Smile to see how much extensibility and
customisation can be achieved within a desktop application. And you
need only look at all the minimally or completely non-attachable
applications out there to see how very not interested the vast
majority of application developers are about using OSA to achieve it.
Take the lessons learnt from OSA, and move on already. There's an
opportunity to really move things forward here; the least Apple can do
is not lash themselves to a dead horse before they've even looked out
the door.
I'll post more comments later (in no particular order), but the above
sets out my basic position.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-implementors mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
