Am 06.12.2007 um 16:02 schrieb Peter Amstutz:

> To answer your question, yes, this requires some way of mapping
> identifiers to network addresses.  My original idea was that the site
> issues a signed document listing one or more hosts ids that are
> authorized for that site, and the host issues a signed document  
> listing
> one or more network addresses it can be contacted at.
Why all the indirections? Wouldn't it be enough to put one or more  
lines of the kind
<host addr="" port="4231" protocol="vip"/>
(port and protocol being opzional) into the site replica document? It  
*is* a signed document already, isn't it?
So if you already got one from somewhere, you only need to check the  
signature once.
You would omit this on an "abstract site" like your interface  
definitions, and imply that the user should choose randomly from the  
given hosts when establishing a connection.

> That contact
> information is propagated through friend-of-a-friend introductions, so
> that if some site tells you to contact another site, it can also  
> provide
> the contact information.  Other name resolution methods (DNS/MDNS,
> distributed hash tables, central metaserver on,  
> or ???)
> would also be a good idea.  Unlike DNS, spoofing replies is much more
> difficult, since the replies have to be signed to coorrespond with the
> same public id you are trying to resolve.
Well, these are two separate things really, aren't they? The first  
ist a matter of key management and distribution, including trust in  
the fact that a key really belongs to the person claiming to own it.  
I don't really see a need to invent something new here, people may  
either use certification hierarchies (X.509) or grassroots cross- 
signing (GPG) at their choice.

The other is the question where you get a (partial) site replica  
document in the first place. If you just follow a link from one site  
to another, you should already have this information (see above),  
assuming that a link includes a minimal replica of the target site  
document including its <site> and <host> parts. If you are not  
connected yet, I'd suggest to leverage the power of URLs. People are  
used to exchange these nowadays, and they can specify any kind of  
data source you could possibly imagine.... WWW, local file, FTP  
server, freenet... Just like torrent files really. Where you get it  
from is not really a problem, since you can always check its  
authenticity if you have/trust in the signing key.

> For the separate matter of mapping human-readable names to site ids, I
> don't have an answer to that.  That's sort of a sticky problem because
> such a system should be hardened against all sorts of abuse (spamming,
> domain squatters, etc) many of which are social and not technical.   
> I'm
> imagine there's been some interesting research into this area, though,
> which would be worth looking in to.
Well.... do we really need names for site IDs? I mean, web pages  
don't have names either, do they? If you want, a site replica  
document could contain a line of the form
<title>My Cool VOS Site</title>
or similar that would show up in history bookmarks and other places  
requiring human readable labels.

>> Ok, so the average user will never be concerned with MyTypeImpl, but
>> only ever interacts with MyTypeWrapper? In this case I agree with
>> reed to drop the Wrapper part and just call the thing MyType.
> The average user is concerned with MyTypeImpl if they are implementing
> new components, which I would hope to be a common operation (as common
> as adding new classes to any object oriented application).  The user
> also needs to supply the correct implementation when instantiating  
> a new
> vobject, since if there are (for example) two implementations of
> IOutputStream, you need to select which one you actually want.  In  
> terms
> of actually calling methods on it, it is isolated from the user via  
> the
> wrapper class, for implementation reasons I discussed previously.
Uh... by "user" I meant someone just surfing a site, or simply  
accessing existing information from some program. This kind of user  
would only ever see a bunch of FooWrappers and wonder about them...
The kind of user you seem to have in mind is actually an author or  
developer, who indeed would need to mess around with FooImpls.... so  
that "users" in the sense above can "use" them. There should be a  
distinction between the two... and the system should be more  
convenient for the user than the author. Like, how many people author  
web pages, and how many just browse them?

> I'm still mulling it over.  It does make the client code easier to  
> read,
> but at the expense of potentially introducing confusion between the
> wrapper classes and "real" classes, which have very very different
> semantics.
I was thinking in the way the established systems like CORBA or RMI  
handle this issue. They already do distinguish between author and  
user, and are optimized for use by the latter on the assumtion that  
there are more of them. I.e. if i want to access a remote Java  
object, I only need its MyType interface and an remote object  
reference. If I want to *create* a new remote object, I have to  
design the MyType interface for the users, and create an MyTypeImpl  
with the actual functionality. There is a hidden third class, a  
MyTypeStub, which is usually autogenerated, and which handles the  
marshalling for remote (or local!) invocations - this is what users  
handle, though they are never aware of it, only of the fact that they  
got a MyType object to use.
So, how is this didfferent from what VOS s5 is supposed to do?

Regards, Karsten Otto (kao)

vos-d mailing list

Reply via email to