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="interreality.org" 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 interreality.org, > 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 vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
