Ray
Hi Andrew
Andrew Lowenstern <andrew_loewenstern@il.us.swissbank.com> writes:
>
> Can anyone point me to some real info on Telescript?
> It all seems like so much vapor to me right now.
General Magic Inc,
2465 Latham Street,
Mountain View,
California 94040,
USA
Tel: 415 261 3800
You can contact GM at the above address for some technical overview
material and press release stuff.
A SHORT summary of Telescript follows...
* The Telescript language is a pure (everything's an object!) object
oriented language which looks a bit Smalltalk-ish.
* Telescript is an interpreted language. To run a Telescript program
you need a Telescript Engine. Various Engines are available for
a number of different platforms. The Magic Cap software running on
Sony and Motorola PDAs consists of a Telescript Engine plus a GUI
plus comms stuff.
* There are two language levels to Telescript: High Telescript and
Low Telescript. High Telescript has an object oriented syntax and
is compiled to Low Telescript. Low Telescript has a postfix syntax
for stack-based interpretation.
* The basic network configuration is to run a Telescript Engine
on each node (computer) in the network. The network of interworking
Telescript Engines provides an abstract homogeneous environment in
which to build distributed systems.
* The most important class in the Telescript language is the Process.
Telescript supports preemptive, prioritized multi-tasking of
Process objects. A Process instance can be thought of as an object
with a life of its own.
* Place and Agent are the two important subclasses of the Telescript
Process. A Place object represents a virtual space in which other
objects can interwork (through local communication). Each Telescript
Engine can support a number of places.
* An Agent object is a Process object which can migrate between Places.
An agent may move between Places on the same Engine, or between Places
which exist on different Engines. Hence the Telescript notion of a
distributed system is a number of distinctly located places and a number
of Agents which move between these Places.
* Places provide meeting locations for Agents. At a Place, Agents can
exchange information and perform computation. Places also route
travelling Agents.
* Telescript supports persistent objects --- Telescript Engines implicitly
save and recover object state information. This is as
a failure recovery mechanism where objects are automatically
recovered to the state previous to a system failure. Persistency is
also transparently supported when objects migrate. When an Agent
transports itself (using the "go" method) from one Place to another
Place on a different Engine: its execution is suspended, its state
information encoded and transferred through the communications
medium, then decoded, and finally the Agent's execution is resumed
at it's new location.
* Agents have "attributes" such as "identify" and "owning authority"
which uniquely identify the Agent and the entity responsible for it.
These attributes may be used for authentication. Telescript objects also
have a "permit" attribute which may be used to limit the amount of
resources which they may consume (e.g. a Place may ask an Agent to pay
it 30 "Teleclicks" before granting it access to some resource).
A secure "permits" feature is crucial to stop Agents from creating
a crash-limited number of clones of themselves, exhausting resources,
or other such anti-social behaviour.
(Apparently you can't define a legal Telescript Place which holds
visiting Agents to ransom unless you can circumvent security features
and hack the Interpreter code!)
* The Telescript world is divided into "regions". Each Engine uses a
"regions" database to route migrating Agents. Places and Agents
are identified using "Telenames":
Telename(Locally-Unique-Name, Region-Name)
Andrew Lowenstern <andrew_loewenstern@il.us.swissbank.com> writes:
>
> On a related note, what about directory services? How would a
> safe-tcl agent locate other agents or hosts that provide the
> services needed to complete it's work? Ideally the agent could
> lookup currently valid hosts that provide the right services or
> locate other agents without the agent being explicitly directed
> by the user.
As I understand it, the "regions" database provides only simple
routing hints. But I think that you're talking about a more
sophisticated trading service (e.g. The ANSA Trader -- plug, plug --
which is service which sits inside a CORBA-like environment and
performs object interface type and property matching).
I think that each Telescript Place provides a trading service to
local Agents. This enables an Agent to request a "meeting"
with another Agent of a "conformant" class (using Telescripts
inheritence rules).
A more global trading service (perhaps a federation of the local
Place trading services) would have to be built as an add-on application.
* Hal <hfinney@shell.portal.com> writes:
>
>What kinds of inter-process communications are done in Telescript?
Telescript Agents can only interact when they are co-located within
the same Place. (There's no RPC-like notion in the Telescript world!)
An Agent (the meeting initiator) can request to
meet with another Agent (e.g. a specific Agent instance, or any instance
of some (sub)class). Assuming that the target Agent is available, the
Place provides the meeting initiator with an `object reference' to
the target Agent. The meeting initiator can then invoke the methods
defined in the target Agent. The "meeting" procedure is asymetric ---
the target Agent is not passed an object reference to the meeting
initiator.
* Roughly speaking, an object may have 3 types of method:
"system" --- invoked by the Engine
"private" --- invoked only by itself
"public" --- inovoked by anyone
* Important methods of the Place class include:
"initialize" --- invoked at instance creation-time. Initialization
maybe "escalated" to its superclass(es)
"entering" --- invoked when an object (an Agent or even another
nested Place) enters the Place or is created
within the Place.
"exiting" --- invoked when an object leaves the Place
"transferredIn" --- invoked when an Agent tries to leave but fails
for some reason (comms failure, invalid address,
etc.)
* Important methods of the Agent class include:
"live" --- the `main' code of the Agent. A codification of the
Agent's destiny!
"go" --- e.g.: self.go(ticket(telename(localName,regionName),...))
I hope that some of you (Safe-)Tcl experts take up the "simulate the
Telescript world"/mobile agents challenge.
Cheers, Ashley
--
Ashley McClenaghan
email: am@ansa.co.uk
tel: +44 1223 568924
address: APM Ltd.,
Poseidon House,
Castle Park,
Cambridge,
CB3 0RD,
UK.