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"
promise.
> > 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?
getLocalHost()
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.
vosIO::CppStdInputStreamImpl::getClassImplementation()
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,
though.
> 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 ]
signature.asc
Description: Digital signature
_______________________________________________ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
