Interesting deployment consideration and good suggestion on a default. Is this default an attribute or an id? Does this default concept apply to only network map or cost map as well, or more general any media type? From the linking relationship, the structure will look like:
cost map 1 -> network map 1 cost map 2 -> network map 2 Hence, if the client uses cost map 2, it implies network map 2. So, default is for cost map? Thanks! Richard On Wednesday, July 17, 2013, Ben Niven-Jenkins wrote: > We can reserve an id for a 'default' map the clients can fallback to. If > there's demand for multiple maps and they provide value clients will > provide hooks to select a map. If there isn't then none of this matters :-) > Ben > > On 17 Jul 2013, at 20:33, Wendy Roome <[email protected]> wrote: > > > I made that proposal before reading draft 17; otherwise I wouldn't have > > bothered. > > > > But if you equate "full network map id" to what I called "network map > > name", draft 17 accomplishes exactly the same thing, minus the central > > registry, and with different syntactic sugar. > > > > BTW, that means that where before a client needed to be configured with > > the uri for the IRD, now the client needs that plus the id name of a > > network map. > > > > I can see that leading to an interop problem down the road, though. I > > suspect most ALTO servers have only one network map. Clients will be > > tested against those servers, and will pick the IRD's one and only > network > > map. Because multiple network maps are rare, clients -- particularly > > "upstream" clients that use an ALTO client library -- won't bother to > > provide a hook to configure the network map id. > > > > That will work fine until the client encounters a server with multiple > > maps, and then the client will just randomly pick one. Or crash. > > > > I don't think much can be done about that, though. > > > > - Wendy Roome > > > > > > > > On 07/17/2013 15:12, "Ben Niven-Jenkins" <[email protected]> > wrote: > > > >> Wendy, Colleagues, > >> > >> I simply do not think we need this level of complexity, registration or > >> constraints. I see the world quite simply. > >> > >> We can have multiple network maps in an IRD so we agreed to allow maps > >> have ids to 'name'/distinguish them. The client needs to match the cost > >> map to the appropriate network map so it matches the network map id with > >> the 'uses' property of the cost map. > >> > >> Whoever publishes the IRD needs to ensure the URIs presented and any > >> underlying servers/software/etc hand out consistent results otherwise > >> that publisher's ALTO service isn't useful. How that is achieved is > >> outside of the ALTO protocol. > >> > >> Clients need to find the appropriate network map id to use if they are > >> several in the IRD. How they find that is outside of the ALTO protocol. > >> If ALTO providers publish multiple maps in an IRD without providing the > >> user or client a mechanism (e.g. through getting a user to configure an > >> appropriate name, or by using some other appropriate mechanism) that > >> provider's/publisher's ALTO service isn't useful. How that is achieved > is > >> outside of the ALTO protocol. > >> > >> So, yes ALTO providers/deployers need to be careful to ensure the > service > >> they offer is useful and ALTO clients need to offer ways for users > (human > >> or machine) to select which map id(s) are of interest to them but none > of > >> that requires work to the base ALTO protocol IMO. > >> > >> Ben > >> > >> On 15 Jul 2013, at 17:15, Wendy Roome wrote: > >> > >>> At the risk of being a nudge, I'm going to suggest what I think is the > >>> only practical way to handle multiple network maps in one IRD. > >>> > >>> Namely, treat multiple network maps the same way we treat multiple cost > >>> metrics: name them, register the names, and define basic semantics for > >>> each network map name. > >>> > >>> That means each network-map service would have capabilities with the > >>> name > >>> of the network map it returns. A filtered map service's entry would > >>> have a > >>> list of names, and a filter map request would allow the client to > >>> specify > >>> the network map name. Cost map services would have to indicate the > >>> network map name as well as the cost-type name. Or we could make the > >>> network-map name part of the cost-type name. > >>> > >>> I'll even suggest a set of network map names to register > >>> > >>> provider -- Has detailed PIDs for the provider's coverage area. As you > >>> get > >>> away from that area, PIDs become much coarser-grained. > >>> > >>> local -- Has detailed PIDs near 'the client' (whoever the perceived > >>> client > >>> is). As you get away from that
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
