|
Note events are instantiated (serialized) as XML messages and event processing is more or less synonymous to message routing,queuing, archiving and rendering
|
|
XML data structures could include general <micro> tags as well as more specific sub-tags for each application
|
|
The micro device display should be similar to display of applications such as memos and mail on existing Palm applications with hierarchical structure
|
So although we use a browser like language (specify messages in XML and render with a device dependent style), the rendering engine is extremely simple compared to a workstation browser
-
All Tango applications will be rendered by same engine on micro device
|
|
One can either view micro Tango as a standalone client or always invoke a full Tango client on a PC and view this as a proxy for micro device
|
We need to provide a general architecture (libraries) to aid the piping (a.k.a. generating appropriate filter and transmitting events through it to Micro Tango Agent) of events from Tango client to micro Tango agent. Note this piping is responsibility of those applications that can be rendered on a micro device
-
We should support Java and JavaScript applications piping from Tango
|
|
As a byproduct of this new system, we will get a whiteboard that serializes drawings to XML (presumably in official VML (vector graphics) dialect)
|
|
Some interesting events are associated with Jini enabled entities registering themselves in a lookup service which registration generates events
|
|
For a pager, use one with a digital interconnect. It is essentially permanently connected
|
For a Palm V, buy digital modems and assume they intermittently dial in to connect to Micro Tango Agent
-
This sends summary of events that have received while palm disconnected. One can choose to discard or process
-
email conduits could be useful resource
-
One can from PC or Micro device, set flags to control which events are queued
|
Note that current Tango JavaScript shared browser (JSSB) has some similarities in architecture with that proposed here.
-
JSSB has two major windows. One (called by Tango) queues all incoming Tango messages. These are looked at in a continuous 0.5 second cycle and either executed, deferred or discarded. This architecture is required as one must wait for browser to load pages before enacting page associated events
-
AS with JSSB, this architecture naturally supporting event archiving.
|
|
Initial steps include thoughtful choice of hardware
|
|
The standard Jini mechanism is applied for each chosen embryo. This effectively establishes an RMI link from Gateway to (SPMD) node which corresponds to creating a Java proxy (corresponding to RMI stub) for the node program which can be any language (Java, Fortran, C++ etc.)
|
|
This Gateway--Embryo exchange should also supply to the Gateway any needed data (such as specification of needed parameters and how to input them) for user client layer
|
This strategy separates control and data transfer
-
It supports Jini (registration, lookup and invocation) and advanced services such as load balancing and fault tolerance on control layer
-
and MPI style data messages on fast transport layer
-
The Jini embryo is only used to initiate process. It is not involved in the actual "execution" phase
|
One could build a JavaSpace at the Control layer as the basis of a powerful management environment
-
This is very different from using Linda (JavaSpaces) in execution layer as in Control layer one represents each executing node program by a proxy and normal performance problems with Linda are irrelevant
|
Outside Index
Summary of Material
Denote Foils where Image Critical
Denote Foils where HTML is sufficient
