Hi Robert, On Thu, Jul 28, 2011 at 1:57 PM, Robert Varga <[email protected]> wrote: > On 07/28/11 13:43, Thomson, Martin wrote: >> >> On 2011-07-28 at 14:56:19, Bill Roome wrote: >>> >>> So the directory server DOES have an authoritative list of uris -- >> >> The IRD is not authoritative. Sorry if you got an impression otherwise. >> The directory is much like a DNS delegation - a hint from the parent domain >> that the child domain might be present at a particular place. >> >> Keep in mind that the IRD might be on a different server to the individual >> resources. > > Coming from HTTP, yes. Two questions arise: > - who has the authoritative information? OPTIONS request seems to be the > last instance, but it does not have to exist...
Well, whether it exists or not is under discussion. Currently, if OPTIONS doesn't exist, the one providing the directory is supposedly authoritative. To answer your question, the last server to give the client a resource's URI is authoritative for that resource. In a REST-ful design (similar to DNS delegation as Martin pointed out), the root (and if used, intermediate) directories only help you get there. > - could we not be a limit this a bit in exchange for greatly simplifying > clients? I'm not convinced this is difficult for clients. For example, beyond code that was already written for requesting and parsing requests, my code for finding the URI for a resource is only 30 lines of code (including logging), plus another 30 lines of code for determining if a particular directory entry matches (which would be significantly reduced if it weren't C++). As Martin pointed out in another thread, cachability is important on these responses, so once those are appropriately specified by servers, the extra RTT's are typically non-existent. > I really would like to see this simplified, as all this complexity does not > seem to be founded on documented ALTO deployment use cases... Please don't let us return to -07.... Seriously though, REST-ful principles aren't as much about capturing existing deployments (there are no deployments that speak this protocol AFAIK). They purposefully allow for very flexible deployment scenarios, and give clients simple tools to allow for such flexible deployments. But, for what its worth, I could easily imagine a deployment scenario in which endpoint cost and filtering are offloaded to a third party. The existing scheme lets a server accomplish that painlessly and hides the actual URLs used by the third party from the original ALTO Server as implementation details. Thanks, Rich > > Bye, > Robert > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
