[cap-talk] Distributed E systems

[Stiegler, Marc D]

It is certainly straightforward to copy objects across vats, or proxy to
the original vat, or do both, as needed in your application. In CapDesk,
for example (I use this as an example since the source is in the E
distribution, you can look at it), the CapEdit editor is given a
(remote) reference to the file that the user double-clicked on (the
double-clicked file may be on a remote server, the CapDesk desktop is
distributed). CapEdit, for simplicity, just sucks the whole file over
the wire, and when the user saves, dumps the whole file back to the file
server. The CapDesk file manager, in contrast, does not cache anything:
if you double-click on a folder on a remote system, the file manager has
to collect all the individual items in that folder for presentation
again, every time (though if I recall correctly, getting the list of
filenames is a single call to the file server, so there not a lot of
calls back and forth to get the basic data. But if you ask for
Properties on a particular file, there is always a complete round trip
to populate the properties window). Much of getting good performance is
designing the messages sent over the wire so you can either pipeline
well or send an appropriately configured whole bag of stuff in a single
request.

Whether you cache, don't cache, or cache and update continously, is
situation specific. All are straightforward for simple applications (and
possible for complication applications, though not necessarily simple
:-). It sounds like you want to have a cache which, when it is modified,
immediately enables continued operation, but simultaneously sends the
modification back to the authoritative source.

There is a fancy version of replicating and updating that is called the
"unum" which is still a research problem. In an unum, a single "object"
has multiple "presences", some of which are authoritative, some of which
are not, all of which update one another. There is a belief (or a wish?)
that there is a pattern for the unum that can be implemented as a
library package so you don't have to roll your own. This does not exist
yet. 

There is a very cheap imitation (very very cheap) of the unum in the
distribution (I know longer remember which app I developed it for)
called the "summoner": you "summon" an object from a remote location,
and get a local copy that has some restrictions on its updatability and
updateness. If you search for "summon" in the distribution source,
you'll probably find it.

--marcs 

-----Original Message-----
From: cap-talk-bounces at mail.eros-os.org
[mailto:cap-talk-bounces at mail.eros-os.org] On Behalf Of Monty Zukowski
Sent: Wednesday, May 24, 2006 8:47 AM
To: Discussion of E and other capability languages; General discussions
concerning capability systems.
Subject: [cap-talk] Distributed E systems

There was mention in Miller's thesis "Robust Composition" about a
distributed E application that copied objects across vats instead of
proxying every object to it's original vat.  Does anyone have more
information on this?

I'm helping architect a distributed, capability-discipline inspired Java
application and right now we're dealing with how we want our proxies to
work, especially with respect to trading off performance for
reliability.  I'm pushing for a communicating event-loop model with
promise objects, like E uses.  Right now we're trying to work out the
communication details on how to propagate changes while still having a
very responsive system.

Thanks,

Monty
_______________________________________________
cap-talk mailing list
cap-talk at mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk