[Sussex] AppleScript and Red Hat 8.0

[Geoff Teale]

Morning all,

I knew I'd come a cropper on this one, but here we go again ;)

Tony wrote:
-----------
> So thanls for lengthy and informative explanation. However, I 
> think there
> are a couple of areas where you have missed the point

If you only saw a couple then you weren't looking hard enough ;)

> 1 All scripting languages are not the same as you infer and 
> therefore cannot
> really be said to do the same job. On this argument, why use 
> anything else
> than assembler? After all, then you really _could_ do 
> whatever you want, and
> at a high execution speed! AppleScript was designed to 
> control the system
> and applications and thus has very little in the way of data 
> structures or
> record handling or general purpose functions.

Agreed.  However the same could be said of most langauges.  If you've ever
written a 'C' program without using a #include then you'll know what I'm
saying.  Even so, AppleScript is a system level control langauge and as such
has few parallel's.  Simplicity is good, especially when you're looking to
make it useful to end users or your average Office programmer.

> 2 The EventQueue mechanism used on the Mac allows 
> programmatic control at
> system level, rather than program-specific API.

*Note.  What follows  is a major assumption on my part.  I haven't spent
much time looking at AppleScript*

Hmmm.  An EventQueue is an exposed aspect of the system's message queues
providing application "event" feedback - effectively a callback from the
application in question.  The "Event" concept being a lot of simplified GUI
development systems (like VB *yuk*) trivialise the concept of interprocess
communication (IPC) so that state changes in contained objects can be acted
upon externally and you don't have to worry that keyboard and mouse
interaction are running in a completely different process to you
application.   Exposing the applications "Events" through the Carbon or
Cocoa API's that the applicaions will be written on top of is all very well
and good and, yes, it could certainly reduce the need for an API for each
application, but once again we're left with three options, either: 

a) every application "Event" is exposed ;
b) only Carbon / Cocoa "Events" are exposed; 
or c) some program specific subset of "Events" are exposed.  

Let's look at each of those cases.  

In case a) you'd have exquisite control over the application but the
liklihood of making it crash is huge.  If your only mecahnism for
communication is to react to and simulate internal events then you're going
to need a massive amount of knowledge about the internal strucuture of a
(usually) closed source program - this represents a very bad idea.  Any good
programmer would like to have absolute control of the access points to their
application - this kind of situation would scare me.

Case b) would limit the AppleScript programmer to the generic functionality
of the operating system.  To derive functionality from an application you
would have to simulate human interaction with the application.  This would
be unecessarily complex.

Situation c) represents a stable and sensible solution but would require
that application developers deliberately expose parts of their program.
This leaves us in the same situation as using an API.

> 3 The Unix philosophy has been abandoned under X (and I agree 
> this is a huge
> shame)

Yes, but even so I doubt there are many things that you would need to script
that cannot be achieved with bash scripting.  Scripting implies one of two
things :

1. No human interaction required - thus no GUI required.

2. Complex GUI task automated by script.

Case 1, as I have already explained, is something UNIX does better than any
other platform.

Case 2 tends to fall into a couple of categories: office automation and
graphics processing.  If you look at the major applications in these fields
on UNIX (GIMP, StarOffice / OpenOffice.org, pretty much everything based on
Qt/KDE etc..) you'll find they support scripting in most popular
languages... more below...
 
> 4 When work has to be done in a particular application because of a
> proprietary file format (such as M$ Access or Quark Xpress) 
> then you have to
> use these particular applications and the environment that 
> created them -
> however much you pine for the simplicity and power of bash. 
> And this means
> you can't use most scriptng languages. For example, were you to open a
> document in, say, Quark and it were to complain that a font 
> or graphic was
> missing, how could you communicate this to your script which 
> would then
> dynamically load it for you?

Hmm.. this problem isn't generally a problem on LINUX.  Using Open Source
means that no file format is propreitary.  The problem here really is that
there is no Quark for LINUX and the majority of the publishing industry uses
Quark.  

Someday soon even the mighty Quark will be challenged.

> Still, one day someone might program up a true LINUX program control
> language and offer it under GPL  ;-}

I think you'll find that there is too much choice out there to have a
language that control all applications without falling into any of the traps
I mentioned earlier.  I do not think that AppleScript fools you into
thinking it is cleverer than it is because a lot of companies voluntarily
conform to Apples programming guidlines.  Tell me - can AppleScript excerise
the same level of control over GIMP running on Mac OS X as it can over MS
Office running on that platform?

> As for Network Neighbourhood, I await tales of your progress 
> with bated
> breath - I hear that Elx does this, but couldn't locate a 
> working server
> today to download the 2 CD images. I think it also does a 
> good job of acting
> as a Linux client on an NT network.

As I said.  Any LINUX box can do this - it's a question of how it is coming
out of the box.  My experience of Elx is that it generally isn't great at
all.  KDE itself will happily integrate an NT or SAMBA network through the
konqueror filebrowser using a filesystem service - it also does the same
thing for music CD's (representing them as a filesystem).  All that Elx is
doing is making a standard link to this part of the filesystem - there's no
rocket science involved - the real hard work is being done by SAMBA and KDE.

Frankly if you want LINUX to work in a workplace you better of getting in
some  LINUX consultants than looking for something in a box to solve your
problem.

> > Straw poll.  How many people think they are likely to be in an
> > office where LINUX is on the desktop but Windows is being used as a
> > fileserver?
> >
> Very few people I suspect - Linux is pretty unuseable 'out of 
> the box' in an
> office environment, so you won't find it in M$ dominated 
> workplaces. BUT if
> it was both easily useable and free then it would spread more. (Dons
> flameproof suit :-})

Hmmm.  Well, in contrast to my last statement this does depend on what box
you get it out of.  All I can say here is it's a question of perspective.
LINUX copes much better in a Windows environment than the other way around.
I still have difficulty imagining many companies who would still want to run
Window's  file servers but run LINUX clients in any great number.  Any other
kind of window's based server can be dealt with easily.

> > 3. Easy resolution setting / changing
> > ======================================
> Valuable info Geoff - thanks very much. Think I'll do a re-install ...


Cool.. :)

The reality of all of this is as follows:

We're getting there!

.. LINUX is developing far faster than any other platform - there are still
leaps to be made and some aspects will probably never change.  In reality
Microsoft's market is where we're going to make ground, Apple isn't really a
priority, frankly OS X can live in a LINUX world much better than in a
Windows world and I'm happy to see it on any desktop.  I use Sarah's iMac in
the front room to run an XSession against my PC in the spare bedroom when I
want to work in the front room (this apeases Sarah for some reason....).

Good talking to you..

-- 
GJT
geoff.teale at claybrook.co.uk




The above information is confidential to the addressee and may be privileged.  Unauthorised access and use is prohibited.
 
Internet communications are not secure and therefore this Company does not accept legal responsibility for the contents of this message.
 
If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.
 
Claybrook Computing Limited is a subsidiary of Claybrook Computing (Holdings) Limited
Registered Office: Abbey House. 282 Farnborough Road, Farnborough, Hampshire GU14 7NJ
Registered in England and Wales No 1287205
 
A Hogg Robinson plc company