On Tue, Dec 04, 2007 at 11:42:30PM -0500, Reed Hedges wrote:
> * Is wrapper locking local or remote?

Local.  Only when accessing objects on the same host, and when an object 
is not already associated with another thread.  Otherwise the call is 
marshalled and queued for delivery, and the caller gets back a "pending" 

>  >     vosIO::CppStdInputStreamWrapper 
> inpVobj(factory.create(getLocalHost(),
>  >               vosIO::CppStdInputStreamImpl::getClassImplementation()));
> Can you explain this a bit more? what is getClassImplementation() and 
> why do you pass its result (what kind of object is its result??) to the 
> factory?  FactoryWrapper (or whatever implementation it's wrapping) 
> seems to be kind of generic?


Gets the singleton instance of the host.  The local host is a special 
kind of site which holds global information about the process, such as 
the site table, threads, and registered implementations of classes.


Gets the vobject (an ImplementationWrapper) representing the concrete 
implementation of the "CppStdInputStream" interface.  The implementation 
vobject links to a function which constructs a new implementation of 
that component.

  vosIO::CppStdInputStreamWrapper inpVobj(factory.create(...));

Use the factory to create a new vobject on the local host, associated 
with the local host site, and add a new CppStdInputStream component.  
Since the return value is a VobjectWrapper, we assign it to a 
CppStdInputStreamWrapper to get the CppStdInputStream API.  This is an 
implicit cast, and is a less verbose version of:

inpVobj = factory.create().queryWrapper<vosIO::CppStdInputStreamWrapper>();

In either case, you can test for validity of the wrapper using an 
implicit cast to bool:

 if (inpVobj) { }
 if (!inpVobj) { }

> Also, what's a site replica?

One of the big ideas of s5 is the notion that a site exists 
independently of a particular host, and that there can be many copies of 
a particular site floating around which are all equally valid so long as 
they have a valid digital signature and revision number.  When you 
import a site replica, you gain knowledge about that site.  You may not 
be permitted to change it, but you at least know that it exists.

> I noticed a few more things that look new:
> 1. (from XOD text) Format for type strings has changed? Everything is 
> prefixed by /OTD?

That's because the types are paths to the actual Class that the type 
represents.  To be completely unambigious, those should probably be 
prefixed with a site identifier and revision tag as well.

 <vobject name="foo" 
type="vos:0011223344556677889900aabbccddee[3]/OTD/vos/FooClass" />

The format is the site public identifier (public key), the revision 
(revision 3) and then the path to the actual class.

> 2. (from XOD text) What's publicId on the <site>?

That is a 128-bit elliptic curve public key, used both to identify the 
site, and to sign updates to the site.  This gives us the property that 
the site is self-identifying, since the public id is also used to verify 
updates to the site.  Thus, by definition, if a signed update checks 
out, it must have been issued by the entity that holds the private key 
corresponding to the public key.

> 3. What's /OTD/vos/Member? What's "owner" mean in the XOD under "Component"?

In general, a member is a field in a struct.  In the case of components, 
it is an embedded child, meaning it is a data field in the component 
which can be made to appear to be a full Vobject through some interface 
and template magic.

> 4. What's /OTD/vos/Lambda?

The data type for a vobject which represents a function.
> Superficial comment: If the user is only really interacting with stuff 
> via Wrapper classes, why not just chop the name "Wrapper" off the end of 
> all those classes? (Or use a shorter suffix.)

I thought about it, but I wanted to make it clear that the wrapper 
classes are actually wrappers with their own sepcial semantics rather 
than being a pointer to the "real" object.  It's worth considering, 

> Another random comment just looking at the surface -- if we're going to 
> be writing XODs to define classes I think XOD needs to be streamlines a 
> bit more.   I for one envision getting really sick of writing "<vobject 
> name=... type=..." all the time...  :)  [We can define XML schemas that 
> just define elements for the vobject child names (or types?). Any XML 
> experts on the list want to help come up with a clever and elegant use 
> of XML here?; maybe even the code generator could generate XML schema or 
> DTD files when new vobject types are defined...?]

I agree, the notation is horrible.  In fact, I started out with a 
different (made up) XML schema that was much more pleasing to work with, 
but I felt it was important to transcribe it in a vobject serialization 
notation in order to bootstrap the system and emphasize that this is the 
actual abstract syntax tree.  It's sort of like lisp in that fashion.

It would be straightforward to write an additional translation layer 
which takes in a more human-friendly format (whether XML, or some C-like 
curly braces block structure) and transforms it to the equivalent VOS 
AST.  It could even be integrated into the import mechanism so that it 
can be loaded transparently.

[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey:  pgpkeys.mit.edu  18C21DF7 ]

Attachment: signature.asc
Description: Digital signature

vos-d mailing list

Reply via email to