On Fri, Apr 04, 2008 at 01:46:46AM +0000, Lalo Martins wrote: > Also spracht Lalo Martins (Thu, 03 Apr 2008 13:40:51 +0000): > > Sorry to resurrect this, but after working with s5 for two months, I > > still have the same concerns, only more so :-) > > Actually, never mind; I had an epiphany ;-) > > Here's basically how it works... > > My VOS browser is looking at a remote site, and finds an object of a type > it doesn't know. Now, for some reason, it wants to introspect this > object (maybe to build a python wrapper?). What can it do? > > Well, it just asks the remote host to send over a replica of the site > containing that class. My local replica won't be considered > "authoritative", since the host don't have the private key, but then > again the remote host doesn't either -- library sites are "ghost" sites, > that no host has the private key for. > > Now, this could easily be done by treating Library objects specially, and > putting in place a system to replicate them. But why make special cases, > when there's already a perfectly good system to replicate sites?
Yes, that's exactly how it is intended to work. That's why limiting access to the private key (signing power) is important to the integrity of the system. It allows you to receive data from third parties on behalf of the source site with some assurance that the data has not been tampered with. Similar to how Bittorrent works, for example. Keep in mind we're only talking about the APIs, not the actual implementation, so it makes sense that your code should bind to a specific version of the API that was written against. Obviously you can't make changes to an API without also changing the client code that uses it. As a third party, if you want to change a class definition, you have the option of extending an existing class to define a class on a site you control. As for managing changes to existing classes, I have been meaning to add a per-class version number system that can be used to determine forwards/backwards compatability. Something along the lines of major.minor.revision, where * different major versions are incompatible (v1 and v2 classes can't interporate at all) * different minor version are backwards compatible (eg v1.4 can access an object of v1.2, but not the other way aorund) * different revisions are forwards and backwards compatible (v1.4.5 and v1.4.10 are interchangable) This would be separate from the notion of site of global revisions at the site level. -- [ 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
