On Thu, Jul 28, 2011 at 11:07 AM, Bill Roome <[email protected]> wrote: > I understand; I sometimes have that affect on people! > > And yes, allowing a directory to identify other directories is > sub-optimal. But it's useful when the entity providing the resource > directory knows there's another server, but does not have the > authoritative answer for exactly what services that server provides. > Hence, "Sorry client, but ya better get the real information from this > guy." > > Actually, here's my proposal in more detail. Each entry in the resource > directory would have one -- AND ONLY ONE! -- media type, and 0 or 1 accept > types. That's sufficient to define the service that entry provides and the > method it expects. > > This does NOT mean that a URI is limited to one service, though, because a > uri can appear in several entries. For example, the following means that > "map-service" responds to a GET and returns the full map, or to a POST and > returns a filtered map: > > }, { > "uri" : "http://foobar/map-service";, > "media-types" : [ "application/alto-networkmap+json" ] > }, { > "uri" : "http://foobar/map-service";, > "media-types" : [ "application/alto-networkmap+json" ] > "accepts" : [ "application/alto-networkmapfilter+json" ] > }, {
One quick note. We already say that this one must indeed be split out: If an entry has an empty list for "accepts", then the corresponding URI MUST support GET requests. If an entry has a non-empty list for "accepts", then the corresponding URI MUST support POST requests. If an ALTO Server wishes to support both GET and POST on a single URI, it MUST specify two entries in the Information Resource Directory. Your point does apply in the general case though (e.g., networkmap and costmap at the same URI). Rich > > I'd also suggest that the resource directory MUST be authoritative (at > least within any Expires time). If the server cannot provide an > authoritative description of the detailed services, then it should have > give the uri of a directory server that can. > > > Given that, is OPTIONS still necessary? > > - Bill Room > > > > On 07/28/2011 13:19, "Thomson, Martin" <[email protected]> > wrote: > >>On 2011-07-28 at 12:33:10, Bill Roome wrote: >>> I would appreciate it if you could explain how my proposal increases >>> the coupling between the client and the server. >> >>I apologise, your proposal did not increase coupling. 'twas the >>expression of philosophy that caused the allergic reaction. >> >>Thinking on it more, the technical proposal - that a directory can >>identify other directories - is perfectly fine. It's suboptimal, given >>that the first directory could just as easily include the second, but >>it's perfectly sound. >> >>There's a problem with resources that don't support GET, which is one of >>the cases where you get 300 responses and where you need OPTIONS >>requests. But the general guidance there is to avoid the creation of >>resources that don't do GET. >> >>--Martin >> >> > > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
