Re: [vos-d] s5 progress and design - OTD XML
Also spracht Reed Hedges (Fri, 07 Dec 2007 10:57:10 -0500): Oh, ok, then my sketch is not really SOD, just a similar thing. Sorry for apropriating the name. I didn't know that you implemented your format (or forgot). Why wasn't it merged into the main S4 repository? Hmm... ehn... that's a good question :-P didn't even think about it. Guess s5 came around before I could finish it? I couldn't access your bzr repository, can you maybe post an example SOD file just so those of us getting nervous about editing all that XML can relax a bit :) Ah yes, the repository was in a temporary location... I now pushed it to http://interreality.org/~lalo/bzr/sod (or for those who can, bzr+ssh:// interreality.org/home/lalo/bzr/sod). I also checked it out there, so you can actually see the source by going to the same URL; the example is at http://interreality.org/~lalo/bzr/sod/doc/examples/3dworld-blocks.sod best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 progress and design - OTD XML
On Fri, Dec 07, 2007 at 06:01:30PM +, Lalo Martins wrote: Also spracht Reed Hedges (Fri, 07 Dec 2007 10:57:10 -0500): Oh, ok, then my sketch is not really SOD, just a similar thing. Sorry for apropriating the name. I didn't know that you implemented your format (or forgot). Why wasn't it merged into the main S4 repository? Hmm... ehn... that's a good question :-P didn't even think about it. Guess s5 came around before I could finish it? I couldn't access your bzr repository, can you maybe post an example SOD file just so those of us getting nervous about editing all that XML can relax a bit :) Ah yes, the repository was in a temporary location... I now pushed it to http://interreality.org/~lalo/bzr/sod (or for those who can, bzr+ssh:// interreality.org/home/lalo/bzr/sod). I also checked it out there, so you can actually see the source by going to the same URL; the example is at http://interreality.org/~lalo/bzr/sod/doc/examples/3dworld-blocks.sod Looks nice. My only comments are that the ...end syntax is a bit unexpected (would have used braces, and/or allow a block to be on one line with some seperator other than newline, like ;), and was initially confused as to what with: meant. Also, to give a property a value and a type you must use with:...end, right, you can't have a one-line property with a type? But anyway, it's nice and minimal and would be a good addition to VOS, I'll add it to xplanner or something. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 progress and design
Am 05.12.2007 um 22:13 schrieb Peter Amstutz: On Wed, Dec 05, 2007 at 11:43:47AM +0100, Karsten Otto wrote: Hi Peter, some questions/comments from the top of my head: What does importReplica() imply exactly? Is this just loading a local copy, or does it include contactig the remote site and merging updates? The idea is this is actually a copy of (a subset) of the site at some revision. You're loading from this copy, which might have been retrieved from the server, or maybe from somewhere else. After loading the replica, you might contact the server to find out if anything has changed between the revision you have and the most recent revision. It is heavily inspired by distributed version control, although the focus is more on disseminating signed updates from a central site than on branching and merging. Ok, I see. But this implies there could be more servers than just one, each hosting a replica. Which one do I contact for updates? With VOP/VIP URLs this was straightforward, but please remind me again, how do I contact a vos:0011223344... key-based site? Is there a name server somewhere? The interface description seems to slowly approach WSDL Land... Have you considered some shorthand syntax to free a developer of all the XML clutter? Or do you envision GUI-based development tools for this (really the only way to live with WSDL if you have to use it)? I agree. It's not high on my own list of priorities, but this would be a good, easy project if someone wants to help out. (hint, hint) I am tempted, but probably wouldn't get around to it for a while due to the workload of my current day job. Anybody else? :-) The fact that you need a *site* for an interface description seems pretty strange to me, even though I am aware you are re-using the XOD stuff for this... but do developers really have to generate a siteID key for every interface they design? Rather pointless, isn't it? While it may make sense to actually have the OTD vobject structure linked on a site that uses it, you usually don't know the target site (s) at development time. Maybe modify the XOD parser to consider the site/siteID optional, or use a shorthand syntax in the first place :-) That's because the site is actually part of the logical namespace. What this means is (site id shortened for brevity): vos:00112233/OTD/vos/FooClass is entirely different from vos:44556677/OTD/vos/FooClass Because the class vobject itself is a different vobject located on a different site. This means an object that implements the first FooClass is not necessarily compatible with the second FooClass. Another way of thinking of it is that the act of defining and making available the interface definition is the same as publishing any other type of data via VOS. Uh, okay... so... The site in this document is just a namespace, which makes sense given the new idea of a site being some abstract thing manifested only by lots of replicas. I.e. when I use the type vos:00112233/OTD/vos/FooClass I am using a replica of the abstract type definition. I was confused since I still though of a site as something you could connect to with Ter'angreal or mesh, while the new kind does not necessarily have any actual servers hosting the replicas. ... Right? A large part of the change in terminology is due to an overall change in thinking. The idea is to not differentiate between local and remote objects per se, but have objects than I can change and objects I need to talk to someone else to change. Hence the notion of our local copy of such objects being a replica, and if we know our local copy is up to date (by checking revisions) then it is trivial to service read requests using the local copy. Ok, so the average user will never be concerned with MyTypeImpl, but only ever interacts with MyTypeWrapper? In this case I agree with reed to drop the Wrapper part and just call the thing MyType. Regards, Karsten Otto (kao) ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 progress and design
On Thu, Dec 06, 2007 at 11:11:31AM +0100, Karsten Otto wrote: Ok, I see. But this implies there could be more servers than just one, each hosting a replica. Which one do I contact for updates? With VOP/VIP URLs this was straightforward, but please remind me again, how do I contact a vos:0011223344... key-based site? Is there a name server somewhere? There's one additional complication, which is that there are sites and there are hosts. A host is a special kind of site which is never replicated and represents a single process/single instance of a server. The goal being that a site can be clustered across multiple hosts. So a site is bound to one or more hosts, and connections are made between hosts rather than between sites. This provides a layer of abstraction between the concrete concept of a site (an actual OS process on a physical computer) and the virtual concept of a site which is replicated many places. Ownership of a site simply means knowing the private key. If you know the private key, you are able to issue properly signed documents that describe the state of (and state changes to) the site. To answer your question, yes, this requires some way of mapping identifiers to network addresses. My original idea was that the site issues a signed document listing one or more hosts ids that are authorized for that site, and the host issues a signed document listing one or more network addresses it can be contacted at. That contact information is propagated through friend-of-a-friend introductions, so that if some site tells you to contact another site, it can also provide the contact information. Other name resolution methods (DNS/MDNS, distributed hash tables, central metaserver on interreality.org, or ???) would also be a good idea. Unlike DNS, spoofing replies is much more difficult, since the replies have to be signed to coorrespond with the same public id you are trying to resolve. For the separate matter of mapping human-readable names to site ids, I don't have an answer to that. That's sort of a sticky problem because such a system should be hardened against all sorts of abuse (spamming, domain squatters, etc) many of which are social and not technical. I'm imagine there's been some interesting research into this area, though, which would be worth looking in to. Uh, okay... so... The site in this document is just a namespace, which makes sense given the new idea of a site being some abstract thing manifested only by lots of replicas. I.e. when I use the type vos:00112233/OTD/vos/FooClass I am using a replica of the abstract type definition. I was confused since I still though of a site as something you could connect to with Ter'angreal or mesh, while the new kind does not necessarily have any actual servers hosting the replicas. ... Right? You've got it. The idea is to move towards content-oriented addressing rather than location-based addressing, at least at the granularity of a site. Of course, for interactive sessions, you maintain a session to an actual server which is the actual site, so that you can exchange updates in real time (for walking around in a 3D world or whatever). Ok, so the average user will never be concerned with MyTypeImpl, but only ever interacts with MyTypeWrapper? In this case I agree with reed to drop the Wrapper part and just call the thing MyType. The average user is concerned with MyTypeImpl if they are implementing new components, which I would hope to be a common operation (as common as adding new classes to any object oriented application). The user also needs to supply the correct implementation when instantiating a new vobject, since if there are (for example) two implementations of IOutputStream, you need to select which one you actually want. In terms of actually calling methods on it, it is isolated from the user via the wrapper class, for implementation reasons I discussed previously. I'm still mulling it over. It does make the client code easier to read, but at the expense of potentially introducing confusion between the wrapper classes and real classes, which have very very different semantics. -- [ 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
Re: [vos-d] s5 progress and design
Am 06.12.2007 um 16:02 schrieb Peter Amstutz: To answer your question, yes, this requires some way of mapping identifiers to network addresses. My original idea was that the site issues a signed document listing one or more hosts ids that are authorized for that site, and the host issues a signed document listing one or more network addresses it can be contacted at. Why all the indirections? Wouldn't it be enough to put one or more lines of the kind host addr=interreality.org port=4231 protocol=vip/ (port and protocol being opzional) into the site replica document? It *is* a signed document already, isn't it? So if you already got one from somewhere, you only need to check the signature once. You would omit this on an abstract site like your interface definitions, and imply that the user should choose randomly from the given hosts when establishing a connection. That contact information is propagated through friend-of-a-friend introductions, so that if some site tells you to contact another site, it can also provide the contact information. Other name resolution methods (DNS/MDNS, distributed hash tables, central metaserver on interreality.org, or ???) would also be a good idea. Unlike DNS, spoofing replies is much more difficult, since the replies have to be signed to coorrespond with the same public id you are trying to resolve. Well, these are two separate things really, aren't they? The first ist a matter of key management and distribution, including trust in the fact that a key really belongs to the person claiming to own it. I don't really see a need to invent something new here, people may either use certification hierarchies (X.509) or grassroots cross- signing (GPG) at their choice. The other is the question where you get a (partial) site replica document in the first place. If you just follow a link from one site to another, you should already have this information (see above), assuming that a link includes a minimal replica of the target site document including its site and host parts. If you are not connected yet, I'd suggest to leverage the power of URLs. People are used to exchange these nowadays, and they can specify any kind of data source you could possibly imagine WWW, local file, FTP server, freenet... Just like torrent files really. Where you get it from is not really a problem, since you can always check its authenticity if you have/trust in the signing key. For the separate matter of mapping human-readable names to site ids, I don't have an answer to that. That's sort of a sticky problem because such a system should be hardened against all sorts of abuse (spamming, domain squatters, etc) many of which are social and not technical. I'm imagine there's been some interesting research into this area, though, which would be worth looking in to. Well do we really need names for site IDs? I mean, web pages don't have names either, do they? If you want, a site replica document could contain a line of the form titleMy Cool VOS Site/title or similar that would show up in history bookmarks and other places requiring human readable labels. Ok, so the average user will never be concerned with MyTypeImpl, but only ever interacts with MyTypeWrapper? In this case I agree with reed to drop the Wrapper part and just call the thing MyType. The average user is concerned with MyTypeImpl if they are implementing new components, which I would hope to be a common operation (as common as adding new classes to any object oriented application). The user also needs to supply the correct implementation when instantiating a new vobject, since if there are (for example) two implementations of IOutputStream, you need to select which one you actually want. In terms of actually calling methods on it, it is isolated from the user via the wrapper class, for implementation reasons I discussed previously. Uh... by user I meant someone just surfing a site, or simply accessing existing information from some program. This kind of user would only ever see a bunch of FooWrappers and wonder about them... The kind of user you seem to have in mind is actually an author or developer, who indeed would need to mess around with FooImpls so that users in the sense above can use them. There should be a distinction between the two... and the system should be more convenient for the user than the author. Like, how many people author web pages, and how many just browse them? I'm still mulling it over. It does make the client code easier to read, but at the expense of potentially introducing confusion between the wrapper classes and real classes, which have very very different semantics. I was thinking in the way the established systems like CORBA or RMI handle this issue. They already do distinguish between author and user, and are optimized for use by the latter on the assumtion that
Re: [vos-d] s5 progress and design
On Thu, Dec 06, 2007 at 05:50:04PM +0100, Karsten Otto wrote: Why all the indirections? Wouldn't it be enough to put one or more lines of the kind host addr=interreality.org port=4231 protocol=vip/ (port and protocol being opzional) into the site replica document? It *is* a signed document already, isn't it? So if you already got one from somewhere, you only need to check the signature once. You would omit this on an abstract site like your interface definitions, and imply that the user should choose randomly from the given hosts when establishing a connection. I haven't implemented this yet, so I haven't committed to a particular way of doing it. The main reason for having hosts identified with distinct ids is so that there is an unambigous identifier without having to get into the ambigities of comparing hostnames and IP addresses. So for example, if a host is hosting multiple sites, you don't make separate connections to the same host for each site. I'm also considering that VOS messages might be sent over multiple different transports, such as TCP/VIP, or HTTP/XML-RPC, or XMPP, or email, etc. So the host-network address binding is very fluid. That said, where available, it does make sense to bundle site-host and host-network address bindings in the same document, for convenience. Well, these are two separate things really, aren't they? The first ist a matter of key management and distribution, including trust in the fact that a key really belongs to the person claiming to own it. I don't really see a need to invent something new here, people may either use certification hierarchies (X.509) or grassroots cross- signing (GPG) at their choice. Well, what I am fundamentally trying to acomplish with VOS is the ability to publish an object store identified using my public key and using the signing ability granted by knowing the private key to control who can issue authorized updates associated with that site. The only guarantee that clients have on receiving the data is that it was authorized by the entity holding the corresponding private key. You're right, particularly when not using human-readable names, there is a significant danger of social engineering attacks -- you don't need to spoof the actual site, you just need to fool someone into thinking that your site is the authentic one. Some kind of certificate PKI system will be necessary. I haven't studied it enough to have a design for it in VOS yet (whether leveraging an existing system, or coming up with something ourselves). I picked elliptic curve cryptography due to fact that the keys are very short (relative to RSA) which facilitates using the complete public key as the primary identifier. At the moment I'm using 128 bit ECC keys, which grants 64 bits of security. Since the public keys are used as public identifiers (effectively GUIDs), there is a tension between providing adequate security, and using keys which are short enough to be used as identifiers without causing message bloat. Well do we really need names for site IDs? I mean, web pages don't have names either, do they? If you want, a site replica document could contain a line of the form titleMy Cool VOS Site/title or similar that would show up in history bookmarks and other places requiring human readable labels. The naming I am concerned with in this case is more like domain names than individual page names. Which is tied up in the issue of certificates, and generally associating an abstract numerical ID with some actual individual or organization. Uh... by user I meant someone just surfing a site, or simply accessing existing information from some program. This kind of user would only ever see a bunch of FooWrappers and wonder about them... Somebody who is just surfing isn't going to see that stuff anyway, any more than you have to wade through a bunch of weird HTML tags just to visit Google. The FooWrapper terminology should just be considered an implementation detail specific to the C++ binding. Ideally a scripting language binding to VOS wouldn't expose that, you'd just see objects of type Foo. In the actual application, you just see a green foo ball in 3D that you can grab and move around. The kind of user you seem to have in mind is actually an author or developer, who indeed would need to mess around with FooImpls so that users in the sense above can use them. There should be a distinction between the two... and the system should be more convenient for the user than the author. Like, how many people author web pages, and how many just browse them? This doesn't make sense. The only people who are exposed to this will be developers, and C++ developers at that. I was thinking in the way the established systems like CORBA or RMI handle this issue. They already do distinguish between author and user, and are optimized for use by the latter
Re: [vos-d] s5 progress and design
I don't know about Karsten, but the reason I have a knee-jerk reaction
against suffixes like Wrapper is that it just feels like cruft, based
on other systems where the word had no consistent meaning, at least from
a user's perspective, it just seemed a hack to extend an API or
facilitate its use without changing the deeper classes, or it was in
fact an implementation detail that just happened to be exposed to the
user.
It's another naming issue I guess. Call it a Handle and use an H
suffix. Or an Accessor. Call it a Lever, I don't know :) Wrapper
just has bad connotations to some of us :) (Maybe like Component) In
the end it will just be something that a C++ user has to learn what it
means, but at first glance they have to have trust that it's actually
very useful and that there's a good reason they have to do that extra
typing.
Reed
Peter Amstutz wrote:
On Thu, Dec 06, 2007 at 05:50:04PM +0100, Karsten Otto wrote:
My concern is that if the wrapper class is named with just the name
stem, the following situation is very confusing:
{
Vobject* foo = getFoo();
delete foo;
// Oops. I think I deleted foo, but all I did was delete
// the wrapper. The underlying object is actually still there.
}
{
VobjectWrapper* foo;
delete foo;
// I know it is a wrapper, so I know I'm just deleting the wrapper
// and that the underlying object is untouched.
}
This is a little contrived, since wrappers are usually stack-allocated
(although the confusion is still there, just not as obvious), but
similar cases can be made for other common operations such as assignment
and comparison.
It's ugly, but it should be considered an artifact of the
implementation. Languages with better metaprogramming facilities (meta
object protocols, in the traditional academic sense) and hopefully
script language bindings should not require this technique.
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 progress and design - sites, hosts, and URLs oh my
Karsten Otto wrote: Ok, I see. But this implies there could be more servers than just one, each hosting a replica. Which one do I contact for updates? With VOP/VIP URLs this was straightforward, but please remind me again, how do I contact a vos:0011223344... key-based site? Is there a name server somewhere? There are two layers, host and site, where before there was just a site. Peter, does the following sound more or less like the way it's going to work or could work, roughly speaking? -- First, you contact a host, then you find the site and its vobjects. You either already have a connection, or you have a URL like vip://interreality.org:4231/MyCoolWorld/thing. You could say that interreality.org:4231 is the name of the host. Then you go looking for the /MyCoolWorld/thing vobject, which is part of some site hosted on this host. You could just send the host the name of your vobject (/MyCoolWorld/thing), and the remote host looks up which of its sites (if it has more than one) that vobject is part of [vobjects on different sites would have to be children of different root vobjects, like /site1, /site2, /MyCoolWorld], and returns a message informing you of your requested vobject's site identity information, you do key authentication, etc. The site doesn't really have a name, but it has its key, and on any given host it has a unique root vobject that all its other vobjects are underneath (though that root could have different names on different hosts).This is not too dissimilar from the site handshaking/negotiation in S4, I think, it just has the extra part where you need to tell the remote site what vobject you want so it can figure out which site to use for that vobject, and tell you. Yes, nobody should really have to every care about the actual site ID/key strings, unless they're debugging something or it happens to be useful in some code to have a unique value that identifies the site (i.e. in S4 you would have used the site's URL for that) or are developing something more advanced involving site replication or distribution or whatever. Or they are suspicious about a site's identity and want to manually verify whether it matches some record . End users (surfers) would still have URLs. Though one thing I do want to get into the client application etc. more quickly than we would have in S4, is reimplementing the service directory we had in S3. It incorporated both online directories of services (e.g. a 3D world), and LAN discovery. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 progress and design - OTD XML
Also spracht Reed Hedges (Thu, 06 Dec 2007 17:46:37 -0500): Or you could use any file format for Vobjects, even COD. Back in S4 I sketched out a possible curly-bracket format called SOD I think (don't remember it exactly anymore though, maybe there's a message about it in the archive?). SOD was a plain-text format which I designed and actually implemented for s4. I will most likely want to port it to s5 :-) (unless someone wants to do it first) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 progress and design
On Wed, Dec 05, 2007 at 11:34:45AM -0500, Reed Hedges wrote: We should also include at this point a reminder of why there's a code generator. If I understand things correctly, the goal is to use the code generator to (a) generate code for different programming languages (b) make it easier for users to generate MetaObject (now called Component) wrapper classes corresponding to different type interfaces (and in different programming languages). The fact that Peter happened to use the code generator to generate VOS itself is, again if I understand it correctly, partly for (a), and partly to make sure it works well. Correct me if I'm wrong Pete. You're on the right track, but there's more to it than that. It provides a set of formal semantics for VOS which are defined externally of a particular programming language. With the spec in hand, you only have to write a code generator (or other metaprogramming layer) and run it against the spec to map VOS onto a new target language. It gives a self-contained type system, so when two programming languages talk about a VOS Class, they are unambigously referring to the same thing. It also encourages developing an OS- and language-independent vobject-based standard library of APIs and components instead of dropping down to the language-specific standard library for common tasks. For example, I've already added InputStream and OutputStream classes as part of VOS in order to read and write files. This means you will be able to read from or write to streams which come from other language runtimes, processes, or hosts. In the case of the C++ binding, the code generator will automate marshalling, unmarshalling, and pipling, which would be tedious and error prone to write by hand (and changes often during development). C++ template metaprogramming doesn't really help here, since templates don't provide the reflection features to be able to say for each method in this class... Finally, the code generator also keeps some other miscellaneous boilerplate code in sync, such as registering classes and implementations, and embedded the correct copy of the interface spec in the executable so that reflection is available at runtime. Rather than simply being a convenient tool, the VOS object model is almost a new language that happens to be hosted on C++. I actually hope to see VOS implemented in other languages (and not just through foreign function interfaces) and think it will be a better fit for higher-level languages that already provide garbage collection, reflection, marshaling, promises, continuations, etc. -- [ 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
Re: [vos-d] s5 progress and design
We should also include at this point a reminder of why there's a code generator. If I understand things correctly, the goal is to use the code generator to (a) generate code for different programming languages (b) make it easier for users to generate MetaObject (now called Component) wrapper classes corresponding to different type interfaces (and in different programming languages). The fact that Peter happened to use the code generator to generate VOS itself is, again if I understand it correctly, partly for (a), and partly to make sure it works well. Correct me if I'm wrong Pete. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 progress and design
Hi Peter, some questions/comments from the top of my head: What does importReplica() imply exactly? Is this just loading a local copy, or does it include contactig the remote site and merging updates? The property lookup example seems a bit verbose for a task that I assume will be quite frequent... Wouldn't this be wrapped into some MetaObject method getOccurrence() : String? The interface description seems to slowly approach WSDL Land... Have you considered some shorthand syntax to free a developer of all the XML clutter? Or do you envision GUI-based development tools for this (really the only way to live with WSDL if you have to use it)? The fact that you need a *site* for an interface description seems pretty strange to me, even though I am aware you are re-using the XOD stuff for this... but do developers really have to generate a siteID key for every interface they design? Rather pointless, isn't it? While it may make sense to actually have the OTD vobject structure linked on a site that uses it, you usually don't know the target site (s) at development time. Maybe modify the XOD parser to consider the site/siteID optional, or use a shorthand syntax in the first place :-) What exactly is the site revision? An interface version in this case? What does this mean on a real site, i.e. virtual world? Does it change with every child addition/removal, or even every nested property value change? If so, what is the datatype, and what to do when it wraps? Regarding naming, there seem to be MyType, MyTypeWrapper, MyTypeImpl... what exactly is the difference between the three? The old distinction Interface, RemoteType, LocalType does not quite seem to fit anymore in the way you use the new code. Sort of confused, Karsten Otto (kao) ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
