Re: [vos-d] s5 site ids

[Peter Amstutz]

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

[Lalo Martins]

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