[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Resolution Simplification
Great questions. Let me also address your question about the XML-as-query.
First of all, yes, several HTTP requests are made to several hosts, and you ask about letting the first host do some sort of "recursive" resolutoin out of a cache (ie have a resolver provide the entire resolution to a client). I actually had a discussion with dave mcalpin that briefly touched on this, and my feeling is that this would be a common way to deploy resolution, and maybe it can be specified by us, but its not specified yet. Because of delegation, there will always be multiple HTTP requests - but the idea is that these requests are *cacheable* - thats one of the main reasons for relying directly on HTTP.
As for using someting beyond GET (ie POST), the motivation here is to promote cacheability. POST requests generally *aren't* cacheable, but GET requests on URIs that are common between different resolutions *can* be cached succesfully.
I think its entirely reasonable to think of a more generic resolutoin process based on explicit XML queries (e.g. in POST messages) and multiple transports. In other words,something like a SOAP infrastructure for resolution. I was trying to do something simpler and easier to develop. I think deploying such an infrastructure might be entirely possible - in the sense that what is described in my proposal could easily be "cast up" into richer semantics. I'm trying to do the "simplest thing that could possibly work", and I don't see the need for full XML queries. I think it may actually not be so complicated to think about a more complex query which includes XML content, but I don't think we should specify that right now because I don't see requirements for it and it complicates the caching story quite a bit.
The issue about getting HTTP through firewalls is legitimate, but I would note that a) there's nothing wrong with performing resolution through a proxy (and a cache) and b) I think it should easy to deploy gateways - such as an smtp gateway. I believe HTTP is a relatively special protocol in the sense that its available in the vast majority of corporate networks. DNS is less so - some networks don't provide access to DNS at all - and only allow web access through a proxy (and only the proxy has access to DNS).
I'm glad you have a positive response to the simplification, in general. I'm hoping that I'm addressing your concerns. I think what you propose could be useful in some situations, but what I'm trying to do now is get out something that would work for as many things as possible and be easy to implement. I'm still positioning this proposal as *a* resolution process for XRIs, not *the* process.
I'd also point out that part of my focus on HTTP is a belief that HTTP is very much a generic "application protocol" and not just a "transport protocol". That is, the verbs GET/POST/PUT/DELETE are actually quite generic and usable in ways which most folks aren't familiar with - in particular the REST architecture is quite compelling for widely distributed interactions. http://internet.conveyor.com/RESTwiki/moin.cgi/FrontPage