Hi Robert, sorry to take so long in getting back with you.  I did take a little
time for the very interesting reading you pointed me to about the E programming
language.

> I am doing distributed objects.  Specifically, I am trying to replicate 
> the Elib framework from E, and I am finishing up the CapTP layer ( 
> http://www.erights.org/elib/distrib/index.html ).   It has some very 
> interesting features, but it is fundamentally a distributed object 
> protocol.

What a neat-looking language!  I don't really understand it, but if it includes
distributed object services built into the language, it ought to encourage
purer domains from developers.  Not the prettiest syntax but certainly a step
in the right direction as programming languages go.

> You may be interested in this paper:  
> http://www.erights.org/data/serial/jhu-paper/intro.html

Interesting, indeed!  Starts off quite readable and exactly the kind to help me
figure out an appropriate security model for Magma.  Unfortunately, it looks
like the paper is yet unfinished.

I've implemented an RBAC-based security framework in Java, but would like to
learn more about the "capability" based model.  I'm still keeping my eyes open
for an elementary paper.  I really hope this paper will be completed and
deliver what it claims to in the Introduction, ".. we do to the notion of
serialization something like what serialization does to objects -- we take it
apart, and then put it back together somewhat differently..".

Do you know whether Mark intends to finish this paper?  I intend check back
later for my interest.  Thanks for the link!
 
> When a graph is to be serialized, in VatA, I'll use substitution to do 
> two things for proxiable objects.  First, make the necessary 
> registration in VatA's export table and get a wirePosition, as well as 
> get any other info needed for the descriptor, such as registering an 
> exported object with an identity. Second, is to actually substitute the 
> resulting descriptor in the graph of objects.
 
> When I materialize (depickle?) the graph, in VatB, I need to do 3 
> things.  First is to build the appropriate object representing the 
> remote proxiable object (a handler).  Second is to make the correct 
> registration for that object in the VatB's import table.  Third is to 
> substitute a proxy on the handler into the graph of objects.

If the "handler" object is what was originally serialized (e.g., the same class
of object) then you should be able to get away with just materializeGraphDo:. 
materializeGraphDo: [ : anObject | ... ] allows you to add post-materialization
behavior for every object materialized (or it's substitute, if you maintain
your own map of substitutions).  If, however, it's different, you may need to
combine the use of a special object-buffer in addition to using
materializeGraphDo:.

> I actually plan on having two Serializers, one for serialization and 
> one for materialization.  These functions happen on different threads.

MaObjectSerializer employs just one class, MaObjectSerializer, so you should
create a separate instance of it that shares all of the oid-machinery, but has
its own internal buffer:

  myMaterializer := mySerializer copyWithNewBuffer

I have never tried it before, but it should theoretically work.  Actually, I
never put exclusive-use Semaphore guards on the oid dictionaries, so that might
be one issue.

> Ok, I get it now.  You were discussing preserving object identity.  
> Here's what's happening in Elib.  The tables are maintaining identity 
> for the objects.  If a given graph, in VatA, has 2 references to the 
> same object, serialization will create 2 different descriptors with the 
> same wirePosition etc.  (will it!? dunno).   During materialization, 
> each descriptor will be bound into the object tables and return the 
> same object.  Since this substitution happens "in-line" all the 
> references will be hooked up appropriately.

This is how Ma object serialization works as well, except on the serialization
side, it will only create one descriptor (called a "buffer" in my framework)
for each serialized object, never two.  Materialization, of course, preserves
identity.

> It seems that my object tables are in fact part of the serialization 
> process and that supports my original guess that I need a special 
> OIDManager for CapTP, if only I knew where to stuff the extra info and 
> discriminate between the different types of descriptors.  At this 
> point, substitution does seem attractive with the warning that I may 
> break identity invariants if I am not careful about my substitutions, 
> and then don't do a become; rely on the user to do the right thing.

Ah, I think I may be reading that you want to store extra information about
each object serialized/materialized, but information that isn't part of the
programs domain.  You mean, for example, object-level security and control
information.





__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com