On Sunday, June 15, 2003, at 04:30 PM, Chris Muller wrote:

> 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.

No worries!  As you can see I am also needing to take my time in this 
discussion, so lets keep it at the slow simmer.  Too bad we can't get 
paid to do squeak full-time!  I need to tinker with your 
ObjectSerializer and just try some of these directions we are talking 
about and learn the oidManager.


>> 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.

Note that I am trying to bring the distributed comms into squeak, not 
implement the object-level security or the E language.  Dean Tribble is 
writing an E translator in Squeak.  The real difficulty is that most of 
the Squeak environment expects synchronous messages, whereas the 
eventual msg send is asynchronous, but that's a different topic.


>> 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.

Yes, this paper was just sent out for feedback in the last several 
weeks.

> 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.

Here is the paper you are probably looking for:  
http://www.erights.org/elib/capability/ode/index.html

>  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!

Yes, I believe so.  He was looking for some feedback on the e-lang 
list.   Here is the start of the thread:  
http://www.eros-os.org/pipermail/e-lang/2003-May/008771.html  If you 
browse the e-lang archives in June, you can find more of the discussion 
(the archive isn't maintaining the full threading, so it requires some 
browsing.

>> 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:.

It is a different object, and it isn't just a handler, it is actually a 
set of objects that represent a remote object.  (I was hoping to avoid 
complicating this discussion).   During serialization of an object that 
is pass-by-proxy, the other side will refer to this object remotely 
with a handler and resolver.   Just above the serialization framework 
is where these descriptors are used to maintain 'session' or virtual 
circuit.  This is the CapTP layer.

During serialization the substitution is (pass-by-proxy object ->  
FarRefDescriptor).   What gets substituted and linked during 
materialization is (FarRefDesc -> {FarHandler, ProxyResolver, FarRef}). 
  The FarRefDesc contains a wirePosition, used to register the 
ProxyResolver in the ImportTable, and an identityHash, since it is a 
comparable object, which is stored in the FarRef.   The FarHandler is 
used to forward message sends to the remote vat.

Just so you can see the code, here is the method used to substitute a 
FarRefDesc for a pass-by-proxy object during serialization:

newFarDescriptor: object

	| swiss hash wirePosition |
	swiss := self proxyMgr swissTable getIdentity: object.
	hash := swiss asByteArray base64CryptoHash.
	wirePosition := objectMap registerExportFromObject: object.
	^ NewFarDesc newOnWirePosition: wirePosition swissHash: hash.

And here is the method that substitutes {FarHandler, ProxyResolver, 
FarRef} for a FarRefDesc during materialization:

getFar: descriptor

	| handler |
	handler := FarHandler newOnConnection: self wirePosition: descriptor 
wirePosition identity: descriptor swissHash.
	objectMap registerImport: handler resolver atWirePosition: handler 
wirePosition.
	^ handler resolver promise

Finally,  previously in the thread I mentioned that there were 4 types 
of descriptors.  Without showing the details of substitution, the other 
types of descriptors are:   ImportDesc, IncomingDesc, and 
NewRemotePromiseDesc


>
>> 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.

This is good to know if we might be able to use the OidManager for 
these registrations and substitutions.  I was thinking that the layer 
above, CapTP, would hook into the substitution mechanisms and so the 
oid-machinery wouldn't be shared.  I would need to protect the capTP 
tables.  Then I would use two independent instances of 
MaObjectSerializer and just sync their respective ClassManagers.

If you are wanting to bring this kind of mechanism into Magma, then 
perhaps we do use a CapTPOidManager, shared between the two instances 
of MaObjectSerializer.


>> 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.

Weell, no, I actually misspoke.  It isn't extra info to the serialized 
object, but proxy info - it describes the remote object rather than 
annotating it.  I can imagine that you might have a use case for extra 
info to the serialized object.  Replicas for instance.

It does represent control info that is used by the next higher layer.  
Object-level security doesn't really exist in a capability model.  The 
link to the Ode paper should describe this for you.

Robert