gmane.comp.lib.vos.devel

Lalo Martins | 8 Feb 10:50

s5 site ids

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

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

Peter Amstutz | 8 Feb 16:32

Re: s5 site ids

On Fri, Feb 08, 2008 at 09:52:40AM +0000, 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.

(Continue reading)

Lalo Martins | 9 Feb 02:02

Re: 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/

Peter Amstutz | 11 Feb 23:43

Re: s5 site ids

On Sat, Feb 09, 2008 at 01:02:15AM +0000, 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 ][ tetron@... ][peter.amstutz@...]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]

(Continue reading)

Lalo Martins | 12 Feb 05:55

Re: 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/

(Continue reading)

Lalo Martins | 3 Apr 15:40

Re: 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 +0000):
> 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
--

--

(Continue reading)

Lalo Martins | 4 Apr 03:46

Re: s5 site ids

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?

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/

(Continue reading)

Peter Amstutz | 10 Apr 18:17

Re: s5 site ids


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.

(Continue reading)

Reed Hedges | 9 Feb 16:35

Re: 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?
>

(Continue reading)

Lalo Martins | 10 Feb 09:18

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

(Continue reading)

Lalo Martins | 10 Feb 18:19

Re: s5 site ids

Also spracht Lalo Martins (Sun, 10 Feb 2008 08:18:05 +0000):
> 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/

Reed Hedges | 10 Feb 18:35

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

Lalo Martins | 11 Feb 02:16

Re: 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/

Peter Amstutz | 12 Feb 23:35

Re: s5 site ids

On Sun, Feb 10, 2008 at 08:18:05AM +0000, 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

(Continue reading)

Reed Hedges | 13 Feb 00:04

Re: 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.

(Continue reading)

Peter Amstutz | 13 Feb 00:39

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

(Continue reading)

Reed Hedges | 13 Feb 00:48

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

Return

Return to gmane.comp.lib.vos.devel.

Advertisement

Project Web Page

Virtual Object System development

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane