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
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 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
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
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 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
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
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
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
