On Tue, Jul 26, 2011 at 7:59 AM, Enrico Marocco <[email protected]> wrote: > Hi all, > > I would like to re-spin the discussion about what features in the > protocol should be mandatory and what should be optional, offering a > slightly different view from an application developer perspective. > > Current version of the protocol defines a minimal set of mandatory basic > features and a bunch of optional services that, with probably the only > exception of the endpoint cost service, basically constitute optimizations. > > This is certainly the ideal situation from a server implementation and > deployment point of view, but I'm worried that from an application > developer point of view it may constitute a disincentive for ALTO > adoption. The case I have in mind is that of applications intended to > run in constrained environment -- in smartphones or browser-embedded > VMs, for instance -- where filtering services would enable optimization > whilst downloading full network and cost maps, and process them locally, > would not be an option.
I think that this is where your point about "optimizations" comes in, as well as Robert Varga's reply below. In such constrained environments, either a provider could offer the endpoint services via the same IRD, or they could setup cache-type ALTO Servers that just gather updated maps from the authoritative ALTO Server, and have the additional logic to provide the endpoint services (replicated as necessary for scalability). Furthermore, this caching ALTO Server doesn't even have to be owned/managed by the same entity as the authoritative one (but of course, you need to trust that entity...) > > I don't have a strong opinion about whether the right approach would be > to put the burden of mandatory implementing the optimization on the > server, or the burden of being always prepared for the worst case > scenario on the application -- or possibly something in between -- and > would appreciate to hear any opinions from the group. The major concern I would have with making all services optional is interoperability. I think David Harrington (our AD) puts it well -- in the end, we need to define standards such that different implementations can speak with each other. It is very important to realize the background for why the current services are defined as REQUIRED vs. OPTIONAL up until now. It seems to be common belief that it was because one would be more useful than the other - that is not true. The rationale was that the OPTIONAL services can be *derived* from the REQUIRED ones. That basically enables the caching ALTO Servers approach I mentioned above. I think it goes without saying that my personal opinion would be to make the maps services required, and the other services that can be derived from the maps service optional. In the case of the endpoint property service (for properties other than "pid"), I don't think it matters much since providing properties beyond "pid" is optional already. That said, we will certainly update the document according to whatever working group consensus says :) Thanks, Rich > > -- > Ciao, > Enrico > > > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto > > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
