Shane Stanley wrote:
>> there's no way in hell I'd trust my own or my customers'
future to anything on Apple's public deprecation list
>
> So how come Kiwi requires appscript? I though you'd abandoned
appscript because it relied on deprecated APIs?
Appscript relies on the Carbon Apple Event Manager which is a
legacy, not deprecated, API. 'Legacy' is the no-man's land between
'fully supported' and 'deprecated': while there's no immediate push
to get off them, but the ADC docs do say not to use legacy APIs for
new development; they're just retained so older codebases can
continue operating until such time as they move to newer APIs
themselves (or Apple decide to push them off). Since there's no
Cocoa equivalents for some essential AEM functions, that effectively
makes appscript a legacy API too.
So I couldn't in good conscience pretend to users that appscript was
a platform with a healthy long-term future. I can't speak for other
vendors, but personally I consider it negligent to stay silent as
other people build work on top of yours if there's any possibility
you're going to yank that platform from under them at some point in
the future - or even just do nothing and let it rot for itself.
(/barb)
As to 'abandoned', the appscript project may be dead, but that
doesn't mean the appscript libraries themselves immediately stopped
working. They were functionally complete and already well
field-tested a couple years before I publicly terminated the
project, so the only time updates should be needed is if Apple
changes/breaks something in the OS or Xcode tools, something
changes/breaks in a new Python 3 release, or some major scriptable
application manages to create some obscure new compatibility
problem[1]. And should that happen I still maintain and occasionally
update the Python 3 version myself, so assuming it's addressable at
my end then I'd do so. I just don't maintain the other appscript
versions or do user support (not for free, anyway) as that's no
longer a good use of my time.
Why isn't this a problem for Manta Toolkit? Well, the reason I can
in good conscience promote MT despite it using appscript is that
I've already designed it to insulate them from any future
appscript/AppleScript-related catastrophes. Users' kiwi-based code
_never_ touches appscript directly. The only part that ever goes
near appscript is pacu's Python code (pacu = Illustrator templating
library), and even most of that code doesn't access appscript, but
works with pacu's internal APIs instead. [2]
This means that if Apple and/or Adobe should someday make it
impossible to communicate with Illustrator via appscript and/or
Apple events, MT users won't suddenly see their entire investment in
MT-based workflows wiped out. At worst, users might have to delay
their OS/CC upgrade for 6-9 months, as that's the time I reckon it'd
take to develop my own sockets/Mach message/etc. bridge for talking
directly to Illustrator's C++ API. So while stripping out and
replacing pacu's appscript-based code would be rather unpleasant for
me, mind [3], once done MT users would not even notice the
difference.[4]
Having worked in and around print publishing and packaging for some
years, and learning from both my own and others' missteps (e.g. at
least Adobe and Avid liked Apple's FCP->FCPX move), I appreciate
professional users don't like seeing their years-long investment in
business-critical workflows summarily trashed under them. TBH, I'd
currently be more concerned for nascent MT users that I get hit by a
bus tomorrow, but that's the reason why I'm releasing the core
components under GPL2: as documentation and tools appear other
automation folks'll hopefully start learning and developing for it
as well, spreading that knowledge around so there's no single
potential point of failure in the wetware either.:) And I'll be
thinking about other contingencies, like class path exceptions and a
"dead man's switch" clause in commercial licences, so if anyone else
has similar concerns I'm keen to hear them if you want to mail me
directly.
HTH
has
--
[1] But Apple hopefully won't yank the Carbon AEM APIs any time soon
(if they did, they'd likely lose Adobe CC and Office AppleScript
support too). And compatibility problems with scriptable apps are
virtually unheard of now as appscript users (including myself) spent
some years beating the tar out of it in both testing and real-world
production use before the final release. (The only recent problem's
been the `ascr/gdte` bug that most notably afflicted iTunes 10.6.3.
But I'm pretty sure that's due to Carbon-based apps' developers
setting the [misleadingly named] `NSAppleScriptEnabled`, in which
case it's really Apple's bad for not telling them "NEVER do that!")
[2] Pacu's internal APIs already provide a fairly clean, robust
abstraction layer between kiwi/pacu and appscript/Apple events/Adobe
Illustrator's Apple Event Object Model. Pacu actually builds a
complete local representation of the .ai document's own
document->layers->page-items: amongst other shortcomings, AI
uses by-index references to identify documents and document
elements, and as any fule kno, by-index references are worse than
useless as soon as you start adding and deleting items or moving
them about. And AI doesn't support by-ID references at all, so I had
to develop my own system to assign unique names to all of the
document's layers and page items and always use by-name references
to locate them. PITA for me, but as long as I've done my job right
users shouldn't ever realize any of this because it's all 100%
invisible from them, even as great chunks of document
appear/disappear/fly every which way before their eyes.:) That it
also insulates them from appscript's indeterminate future is just a
handy bonus.
[3] Adobe SDK makes Dark Lord Cthulhu whimper in his Slumber.
[4] Kiwi-only users wouldn't be affected at all. MT users who've
written their own Python-based pacu plugins might have to make some
changes though since some of pacu's internal APIs would change.
(While those APIs handle a lot of the hard/complex/common
interactions, some simple/rare tasks may still require using
appscript directly.) But any such changes should be quick and easy
compared to the pain of the initial AE/AEOM->sockets/C++ port
which I'd absorb, so I'm not too worried about their guts, only
mine.;p
|