Re: [vos-d] s5 site ids
On Fri, Apr 04, 2008 at 01:46:46AM +, Lalo Martins wrote: > Also spracht Lalo Martins (Thu, 03 Apr 2008 13:40:51 +): > > 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
Re: [vos-d] s5 site ids
Also spracht Lalo Martins (Thu, 03 Apr 2008 13:40:51 +): > 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? 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 site ids
Sorry to resurrect this, but after working with s5 for two months, I still have the same concerns, only more so :-) Also spracht Lalo Martins (Tue, 12 Feb 2008 04:55:19 +): > Also spracht Peter Amstutz (Mon, 11 Feb 2008 17:43:45 -0500): >> With regard to shipping the private key, my thinking is that publishing >> an API is like specifying a protocol, and that you really want a way of >> unambigiously referring to a specific API as published by a specific >> entity at a specific version. > > Hmm... no, I don't think I for one want that. It would mean I can't > make changes to third-party library from source A and still have > third-party software from source B work against it without a manual > hack-and- recompile. That would be against the spirit of Free Software, > and the letter of the LGPLv3 (which I see you picked for s5 and I > approve of). > > Yes, it would be nice to have a way of *referring* to a specific (...) > as you say. But having all code by default *depend* on a specific > version published by a specific entity? Bad idea, IMO. > > For the matter, I don't think Libraries should be distributed as a site, > at all. I think they should just import the Library object into the > local host (possibly inside some "safe" location like /otd or /libraries > or even /lib). But it seems you have put some thought behind this > decision; would you mind sharing your reasoning with us? 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 site ids
Yeah, I think we should push and see how effectively we can really use VOS for and develop tools and practices for that. For example, if we're working on the UI client and want to put the available types in a menu. You could write a for loop that goes through the types and puts each thing in the list. Or you could write a tool that takes any Vobject and lists its children in a menu, and updates the menu for changes, etc. If you can get the tool right, you can reuse that in a bunch of other places in the UI. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 site ids
You've got it. Setting up aliases based on prefix at the top of the XOD
file was exactly the solution I had in mind to the verbose-site-ids
problem. Similarly in the code generator we just need to emit a macro
which hides the scary site namespace.
On Tue, Feb 12, 2008 at 06:04:50PM -0500, Reed Hedges wrote:
>
>
> In VOS it in fact would be easy to build a little tree of the types with
> different names to make them easier for people to work with, while
> keeping their real names hidden.
>
> So you can make an object like "/t" and select out the specific top
> level versions used from the containers ("namespaces"?) with the big ids.
>
> E.g.
>
> /t/vos -> /vos:0011223344556677889900aabbccddee/vos
>...Has various children for core types...
> /t/a3dl -> /vos:0011223344556677889900aabbccddef/a3dl
>...Has various children for 3d types...
> /t/mytypes -> /vos:992288337744beffc38aa3712cdd219a8e/mytypes
>...Has various children for custom types...
>
> /foo type="/t/mytypes/foo"
> /bar type="/t/a3dl/object3d"
>
> Maybe we even enshrine a container like /t or /_types as standard place
> to put the "working set" of types, as a convention that all user
> interfaces use, and so when they are telling a user what the type of a
> vobject is, they can just strip off the prefix, or when preseting the
> user with a list of possible types, just provide a listing (or tree
> view) of the children of /t, etc.
>
> Or a UI can just look at the type definition to get a user friendly type
> name.
>
> But OK, in the general case, we need to come up with ways like this to
> help users navigate vobjects, whether in a particular application or in
> VOS stuff like this, without having to put a lot of special stuff in the
> user interface clients.
>
> Reed
--
[ 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 site ids
In VOS it in fact would be easy to build a little tree of the types with
different names to make them easier for people to work with, while
keeping their real names hidden.
So you can make an object like "/t" and select out the specific top
level versions used from the containers ("namespaces"?) with the big ids.
E.g.
/t/vos -> /vos:0011223344556677889900aabbccddee/vos
...Has various children for core types...
/t/a3dl -> /vos:0011223344556677889900aabbccddef/a3dl
...Has various children for 3d types...
/t/mytypes -> /vos:992288337744beffc38aa3712cdd219a8e/mytypes
...Has various children for custom types...
/foo type="/t/mytypes/foo"
/bar type="/t/a3dl/object3d"
Maybe we even enshrine a container like /t or /_types as standard place
to put the "working set" of types, as a convention that all user
interfaces use, and so when they are telling a user what the type of a
vobject is, they can just strip off the prefix, or when preseting the
user with a list of possible types, just provide a listing (or tree
view) of the children of /t, etc.
Or a UI can just look at the type definition to get a user friendly type
name.
But OK, in the general case, we need to come up with ways like this to
help users navigate vobjects, whether in a particular application or in
VOS stuff like this, without having to put a lot of special stuff in the
user interface clients.
Reed
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 site ids
On Sun, Feb 10, 2008 at 08:18:05AM +, Lalo Martins wrote: > Also spracht Reed Hedges (Sat, 09 Feb 2008 10:35:25 -0500): > > The new type IDs are still bothering me a bit too (among other things, > > like the code namespaces). A huge advantage of the old user-invented > > type names is that they were natural to understand and easy to remember. > >We're going to have to do a lot of cutting and pasting, and when we > > get one digit wrong, will be tearing our hair out over it. (Or the only > > option will be to use the GUI tool.) This is a result of the design decision to have the interfaces be reflectively described using VOS. Since the API is described using Vobjects, and the vobjects must be located on a unique site, references to vobjects must include site identifiers. It's worth pointing out that XOD is extremely low level and not really intended as the primary way of editing vobjects, but it is all we've got at the moment. I am thinking about writing some tools that will take care of some of the house cleaning task like fixing paths and assigning identifiers to individual vobjects in order to transform a partially specified file into a fully specified one. > AIUI from IRC conversations, the site IDs won't actually be visible to > the application programmer later on; we'll deal only with IDs like "/vos/ > core/StringProperty". (I'm not sure about the code namespaces, but I > hope some simplification is intended there too ;-) ) Peter has actually > told me a few days ago that side IDs being required for the type > attribute in XOD is "a bug". For now, we cope; the IDs are extra work, > but not really a killer. Actually it is the other way around. The bug is that the type attribute does *not* presently require a site id, due to a quirk (well really a hack) in the way it uses the type attribute string to look up which component implementation to use. It ought to require the site id so that it unambigiously refers to a specific vobject class type. > > Also, what in the HelloWorld example is autogenerated and what isn't? I will have the code generator insert comments into the files so you know the difference. > Each Namespace "world" gets a "world.hh" with wrappers and interfaces, > plus "worldComponents.hh" and "worldComponents.cc" with components. > It's not yet 100% clear to me when "user" code should #include "x.hh" > or "xComponents.hh"; I believe if you need to create a new instance of > something, you need "xComponents.hh", otherwise "x.hh" will allow you > to > work with existing objects. Each "xComponents.hh" already > #includes "x.hh", so you never need both. As you said, "x.hh" gives you the interfaces, "xComponent.hh" gives you the implementations. > And each Class or Lambda "foo" gets its own "foo.hh" and "foo.cc", where > you'd put the concrete implementation. These don't get overwritten if > they exist, since they will contain handwritten code. (Which makes it a > bit of work to cope with API evolution, but you can always point the > generator at a new, empty directory, then copy-paste.) One way to manage this would be to put in comment guards that indicate a certain section of the file is replaceable, and update that section for API changes. > This naming pattern unfortunately means you can't have two > "things" (class, function, namespace) on the same directory. Whether > that can be a problem is illustrated by helloworld itself: if you write a > "Library" to contain only one single class, the most natural naming would > be for Library, Namespace and Class to have the same name. Suggestions > on how to fix this are appreciated, I have no idea myself ;-) (Maybe > something like "/helloworld/core/HelloWorld"?) The code generator should probably tack on something to the file name so you get HelloWorldLibrary.cc, HelloWorldNamespace.cc and HelloWorld.cc. -- [ 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 site ids
Also spracht Peter Amstutz (Mon, 11 Feb 2008 17:43:45 -0500): > With regard to shipping the private key, my thinking is that publishing > an API is like specifying a protocol, and that you really want a way of > unambigiously referring to a specific API as published by a specific > entity at a specific version. Hmm... no, I don't think I for one want that. It would mean I can't make changes to third-party library from source A and still have third-party software from source B work against it without a manual hack-and- recompile. That would be against the spirit of Free Software, and the letter of the LGPLv3 (which I see you picked for s5 and I approve of). Yes, it would be nice to have a way of *referring* to a specific (...) as you say. But having all code by default *depend* on a specific version published by a specific entity? Bad idea, IMO. For the matter, I don't think Libraries should be distributed as a site, at all. I think they should just import the Library object into the local host (possibly inside some "safe" location like /otd or /libraries or even /lib). But it seems you have put some thought behind this decision; would you mind sharing your reasoning with us? 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 site ids
On Sat, Feb 09, 2008 at 01:02:15AM +, Lalo Martins wrote: > Yet, you didn't address my actual point ;-) > > I know what site IDs are supposed to be for. My question is -- do we > really want libraries to "ship" as a separate site each? I realise the > key space is pretty large, so "polluting" it is probably no big deal, but > I see no big advantage in this case. (You would need to ship the private > key, anyway, right?) In VOS terms, a "Library" is a set of interfaces, not concrete classes. This is why the "Implementation" objects are separate from the Class objects. This idea needs to be developed more, though, since even within the VOS type system itself I have found it useful to have both abstract classes (that cannot be instantiated ever, interface only) and concrete classes. With regard to shipping the private key, my thinking is that publishing an API is like specifying a protocol, and that you really want a way of unambigiously referring to a specific API as published by a specific entity at a specific version. If you let everybody have the private key then you cannot guarantee that, because anyone could produce a signed API document. One of the foundation concepts in s5 is that ownership of a private key implies the ability (and responsibility) to coordinate changes to that site so that you don't have conflicting replicas floating around from different sources. -- [ 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 site ids
Also spracht Reed Hedges (Sun, 10 Feb 2008 12:35:21 -0500): > Thanks! Does one just run voscodegen with the xod file as input to > generate the code? $ cd debug/stage/bin $ ./run.sh ./voscodegen -o ../../../src/app/helloworld ../../../src/app/ helloworld/HelloWorld.xod 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 site ids
Lalo Martins wrote: > AIUI from IRC conversations, the site IDs won't actually be visible to > the application programmer later on; we'll deal only with IDs like "/vos/ > core/StringProperty". (I'm not sure about the code namespaces, but I > hope some simplification is intended there too ;-) ) Peter has actually > told me a few days ago that side IDs being required for the type > attribute in XOD is "a bug". For now, we cope; the IDs are extra work, > but not really a killer. Aha, that's nicer then, and sounds similar to how I was hoping it would work (with the name (e.g. "StringProperty") as the actual name used by humans). I will miss the foo:bar type syntax, but that's OK I guess if in the new syntax things are equally expressive but terse. Curious what the "bug" is; what's missing from s5 that will fix this? (Curious so I can understand S5 a bit more.) > All C++ files except for main.cc (and in my branch, plugin.cc) are > generated. Here's how I observed it works: Thanks! Does one just run voscodegen with the xod file as input to generate the code? Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 site ids
Also spracht Lalo Martins (Sun, 10 Feb 2008 08:18:05 +): > This naming pattern unfortunately means you can't have two "things" > (class, function, namespace) on the same directory. ... two "things" (...) with the same name in the same directory. 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 site ids
Also spracht Reed Hedges (Sat, 09 Feb 2008 10:35:25 -0500): > The new type IDs are still bothering me a bit too (among other things, > like the code namespaces). A huge advantage of the old user-invented > type names is that they were natural to understand and easy to remember. >We're going to have to do a lot of cutting and pasting, and when we > get one digit wrong, will be tearing our hair out over it. (Or the only > option will be to use the GUI tool.) AIUI from IRC conversations, the site IDs won't actually be visible to the application programmer later on; we'll deal only with IDs like "/vos/ core/StringProperty". (I'm not sure about the code namespaces, but I hope some simplification is intended there too ;-) ) Peter has actually told me a few days ago that side IDs being required for the type attribute in XOD is "a bug". For now, we cope; the IDs are extra work, but not really a killer. > Also, what in the HelloWorld example is autogenerated and what isn't? All C++ files except for main.cc (and in my branch, plugin.cc) are generated. Here's how I observed it works: Things are packed in Library and Namespace objects. Inside a namespace, you'll usually have classes (Class) and functions (Lambda). Each Library "hello" gets a "helloInit.cc", responsible for registration of all interfaces/components in the Library. Each Namespace "world" gets a "world.hh" with wrappers and interfaces, plus "worldComponents.hh" and "worldComponents.cc" with components. It's not yet 100% clear to me when "user" code should #include "x.hh" or "xComponents.hh"; I believe if you need to create a new instance of something, you need "xComponents.hh", otherwise "x.hh" will allow you to work with existing objects. Each "xComponents.hh" already #includes "x.hh", so you never need both. And each Class or Lambda "foo" gets its own "foo.hh" and "foo.cc", where you'd put the concrete implementation. These don't get overwritten if they exist, since they will contain handwritten code. (Which makes it a bit of work to cope with API evolution, but you can always point the generator at a new, empty directory, then copy-paste.) This naming pattern unfortunately means you can't have two "things" (class, function, namespace) on the same directory. Whether that can be a problem is illustrated by helloworld itself: if you write a "Library" to contain only one single class, the most natural naming would be for Library, Namespace and Class to have the same name. Suggestions on how to fix this are appreciated, I have no idea myself ;-) (Maybe something like "/helloworld/core/HelloWorld"?) 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 site ids
The new type IDs are still bothering me a bit too (among other things, like the code namespaces). A huge advantage of the old user-invented type names is that they were natural to understand and easy to remember. We're going to have to do a lot of cutting and pasting, and when we get one digit wrong, will be tearing our hair out over it. (Or the only option will be to use the GUI tool.) Why not have a type/class have separate "secure" (crypto) ID, and name. When you use a human-readable name in the UI client or in a XOD or whatever, VOS could just look up the OTD/record of the type/class and gets its crypto ID, and throw an error or ignore it if there are name conflicts or not found. In the actual internal inter-object references/links it would use the crypto ID. Also, what in the HelloWorld example is autogenerated and what isn't? Reed Lalo Martins wrote: > Is there any rhyme or reason to site ids? > > If all libraries will ship a separate site (as XOD or something) with > their OTDs, won't that pollute the site id space? > > And aren't them bound to clash at some point? Maybe set up a registry of > library site ids somewhere in the website? > > Or is this (library OTD) going to be substantially different later on? > > best, >Lalo Martins -- http://interreality.org/~reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 site ids
Yet, you didn't address my actual point ;-) I know what site IDs are supposed to be for. My question is -- do we really want libraries to "ship" as a separate site each? I realise the key space is pretty large, so "polluting" it is probably no big deal, but I see no big advantage in this case. (You would need to ship the private key, anyway, right?) 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 site ids
On Fri, Feb 08, 2008 at 09:52:40AM +, Lalo Martins wrote: > Is there any rhyme or reason to site ids? The current "testing" site ids are not "true" site ids. The site id is actually supposed to be the public half of a public/private key pair using elliptic curve cryptography. A 128 bit key yields about 64 bits of security. > If all libraries will ship a separate site (as XOD or something) with > their OTDs, won't that pollute the site id space? > > And aren't them bound to clash at some point? Maybe set up a registry of > library site ids somewhere in the website? The idea is for site ids to be globally unique, since there is only a 1/2^128 chance of generating a collision. In order to claim to be a site you have to prove that you know the corresponding private key, thus you can't just pick an aribtrary public site id (unless you know how to work backwards to get the private key, in which case the NSA would like to have a word with you.) > Or is this (library OTD) going to be substantially different later on? I understand your confusion, it isn't very meaningful at the moment because it is not yet doing any of the digital signature checking that I have planned. I need to write a tool that spits out public/private keypairs for use with VOS. -- [ 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
