craig@gpu.utcs.utoronto.ca (Craig Hubley) (09/01/89)
All right, I know this is long, but if you're interested in interoperable
applications, ARexx, scripting languages, and the capabilities they offer
but never actually seem to deliver in practice, it'll be well worth reading.
For the price of adding a very few commands to AREXX it might be possible
to have a fully automatic network-style service system, customized to your
tastes, as object-oriented as you can stand, and scalable to boot, all
running on your very own little Amiga.
Linda: (named after the second 'countess' Lovelace, and much sexier than Ada)
For those of you who haven't heard of it, Linda is a parallel-processing
extension to any traditional language. It's been added to C, C++, PostScript,
and many others. A best first reference is 'Linda in Context', April 1989
issue of the 'Communications of the ACM', by Carriero and Gelertner.
Yale University wrote Linda. It's presently available across a lot of
platforms, most notably the Cogent XTM, where their version, Kernel Linda,
has been used as the basis of an entire transputer-based parallel Unix.
Source and porting deals are apparently available from an outfit called
SCA (Scientific Computing Associates) that is commercializing it. They
apparently want to do a lot of ports, for research and commercial uses.
Basically, Linda defines and maintains an asynchronous unbounded unsequenced
set called a 'tuple space' that contains structured 'tuples'. A tuple can
be any set of data, to wit:
(4, 5, "My Uncle Fred")
(x, 56, "My Aunt Freda", "My Dog Sue", yyz)
(x, y, z*)
are all tuples. Linda always inherits its data types from it's 'host'
language. The primitives it adds are simple:
out (tuple) - put a tuple in tuple space
eval (tuple with calculated fields) - put a process in tuple space,
when all calculations are finished it becomes a data tuple.
in (pattern) - search tuple space and return any tuple matching the
pattern - this tuple is removed from tuple space.
rd (pattern) - equivalent to in followed by an immediate out,
non-destructive read, leaves the tuple in the tuple space.
Tuple spaces will probably shortly become first-class objects so that you
can pass around references to multiple tuple spaces with impunity. Standard
Linda presently defines only one space, but by judicious use of coded fields
you can simulate multiple spaces easily, though you can't do proper recursion.
SCA's (and Yale's) Linda is a preprocessor, that compiles references to the
tuple space into shared memory, semaphores, message ports, sockets,
or whatever else is available to implement parallelism on a target system.
Note the approach is just as good on a non-parallel machine to *unify the
many ways of talking back and forth to other programs*.
What does all this have to do with the Amiga ? Good question. I just
answered it.
First of all, a tuple space that held requests for services in some
standardized (by developers) format could go two steps beyond the present
ARexx enthusiasm. Editors for every IFF type, compilers, mail servers,
printing tools, etc., etc., could all inform a central 'service broker',
by dumping appropriately coded tuples into the space, that their services
were available. The service broker could record these, and might even
maintain a list of programs that were capable of providing each service.
When a request for that service shows up in the space, the broker would
look at it (using rd), determine its priority (as noted in a field,
probably), and load the appropriate program when there is space. The
program would announce it's service availability to the space, so the
broker knows it loaded, and that tuple would immediately be eaten by the
broker. If a program found it's tuple still there later, it would know
the broker didn't know it was there or had crashed or something. When
no service requests have shown up for a long time, the service might be
unloaded. Or a schedule file, or set of scripts, might configure the
service broker to deal with my particular set of problems.
None of this conflicts with ARexx, which can continue controlling
programs as normal, or better yet, acting as a service envelope,
putting appropriate service-announcement tuples in the space, reading
service requests and satisfying them by controlling other programs.
Each ARexx program could be a service. The *service broker itself*
would probably be an ARexx program.
*All of this can be done, it seems, JUST by adding Linda to ARexx!*
These interface issues aside, there don't seem too many bars to actually
putting Linda on the Amiga. The Amiga's OS is a reasonable multitasking
system but which few people have bothered to really exploit, though it is
actually very efficient. The Amiga also has a quite large body of very
interoperable software that obeys its own IFF tagged file format rules and
often programs can be controlled via an AREXX port which is opened up
to an IBM-mainframe-compatible scripting language. This makes it quite
feasible to write very interoperable systems of small programs, but the
environment for programmers leaves something to be desired. An Amiga Linda
might prove a good testbed for Linda's suitability for providing networking
services, etc., since so many dedicated hackers (can I see hands? :-)) own
these machines. Relying on facilities provided through Linda would also make
these programs more portable. There was a lot of talk about building a
standardized IPC facility to manage control and data ports opened up to various
programs, so they can offer services to each other. In retrospect, what we
were looking for when we were discussing IPCs and service brokers, was Linda.
Note how easily the mechanism extends to parallel machines, including networks
of all kinds.
Certainly Amiga developers, alone among commercial developers, have shown an
uncommon willingness to adhere to standards, even those not originally
promulgated with the machine (IFF was in fact defined by Electronic Arts after
the machine was released - today all applications that expect to survive have
to support it. AREXX had a similar history, though it's not yet 'mandatory').
Perhaps this comes with being a small and disciplined development community
that has to stick together to survive. Maybe we can lead the way again.
From a research point of view, having a version of the system available on
a cheap machine multiplies an applications test-base immensely. From a
commercial standpoint, it makes a wider community of users potential customers.
In any case, I think they'll like the idea of making it available on a cheap
machine whose development community has already shown itself willing to
adopt constructive new standards for interoperability. Linda could serve
as the basis for a really cool 'service' system on the Amiga, as discussed
above, and recapped here:
- applications would register their named 'services' with a registry,
basically describing the interface required to 'Edit a HAM file' or
'send mail' or 'print PostScript'. A set of conventions would let each
small program define its capabilities unambiguously. ARexx would be one
way of defining and providing new capabilities directly to the service
system. Linda would hold the data and file references while the
necessary server programs were found and started up. This could proceed
according to a set of rules set up by the user. Linda's asynchronous
interface would let 'producer' programs rock on while 'consumer' programs
took their time catching up. Of course, there would be some limits, but
a decent cacheing scheme, and the use of file references for large items,
would ensure that these were rarely if ever seen.
- A 'service bureau' would read the requests sitting in the space to see
if any programs had to be loaded and started to deal with them. It would
also check to see if any non-essential services were still running for
which there had been no input for some period of time. This could all be
part of the rules set up by the user.
So imagine this interface:
I want to print a PostScript file. I've already written an ASCII file
to the disk that contains PostScript instructions. Now I dump a tuple in
the 'service' space (or just starting with a field 'SERVICE_REQUEST'):
("SERVICE_REQUEST", "PRINT", "FILENAME", "POSTSCRIPT"). None of this
data is volatile, since the filename is also maintained by the FS. Note
that this could be very messy if I was passing handles, so I pass names.
That service request may sit there for an hour before there is enough
memory space to load the PS interpreter and process it. That's fine.
The PS server may also be mandated to destroy the .ps file, but that's
the business of the server itself. If I want instant service, presumably
I'll have to include "PRINT" on a list of quick-response services, or
else have a field for indicating urgency of request that all app. programs
would respect.
All this for the price of adding Linda to ARexx.
Comments ? Flames ? Kudos ? Better ideas ?
Please reply by email as I don't get to read comp.sys.amiga.tech often
anymore... sigh.
Craig Hubley -------------------------------------
Craig Hubley & Associates "Lead, follow, or get out of the way"
craig@gpu.utcs.utoronto.ca -------------------------------------
craig@gpu.utcs.toronto.edu mnetor!utgpu!craig@uunet.UU.NET
{allegra,bnr-vpa,decvax,mnetor!utcsri}!utgpu!craig craig@utorgpu.bitnet
--
Craig Hubley -------------------------------------
Craig Hubley & Associates "Lead, follow, or get out of the way"
craig@gpu.utcs.utoronto.ca -------------------------------------
craig@gpu.utcs.toronto.edu mnetor!utgpu!craig@uunet.UU.NET
{allegra,bnr-vpa,decvax,mnetor!utcsri}!utgpu!craig craig@utorgpu.bitnet