On Mon, Oct 24, 2011 at 10:52 AM, Sabine Randriamasy <[email protected]> wrote: > > > Richard Alimi a écrit : >> >> I don't have any objections with leaving this as an extension. >> >> Sabine - are you still intending to fill out the details in >> draft-randriamasy-alto-multi-cost? Perhaps that could be the first >> ALTO protocol extension :) >> > > Hi > > Yes, I am working on it. The trade-off between options 1 and 2, depends on > the service. > > - For the EP Cost Service, (POST method), option 2 providing a vector or > array of multiple EP Costs or Properties seems to be the simplest way. > - For the Filtered Cost Map service (POST method), option 2 also looks > easily feasible if the filtered volume of information is moderate (assuming > we know what moderate means). > The 2 above services use an order for the components of the cost/properties > vector that is specifed in the IRD of the ALTO Server. Which means that the > multi-Cost/Property Service would be implicitely declared in the IRD. > > - For the Cost Map Service (Get method), we may bump into scalability issues > id the map is "too big". In that case option 1 looks preferable, with > possibly a limitation on the number of Cost maps per ALTO transactions > specified in the IRD.
Just to keep options open, another possibility is to do a POST to the server, and the server may redirect to an alternate location from which the client can perform a GET. Rich > > Sabine > > >> I could imagine a couple of ways the extension could go: >> (1) Design a new service such as the multicost map service. This is >> easy within the current protocol (adding new services to the IRD is >> easy without breaking existing clients). >> (2) Treat queries for multiple cost types the same as a query for a >> cost type that is vector (I think this was basically the way we were >> heading in the design discussion previously on the list). I think >> this requires a bit of a change to the base protocol, but one that we >> proposed a while back (in particular, opaque cost types). I'll ping >> that thread to see if there are any objections to adding that in this >> revision and we can discuss on that thread if there are. >> >> Thanks >> Rich >> >> On Sat, Aug 27, 2011 at 12:29 PM, Reinaldo Penno <[email protected]> >> wrote: >> >>> >>> I prefer 1. >>> >>> >>> On 8/26/11 11:01 PM, "Enrico Marocco" <[email protected]> >>> wrote: >>> >>> >>>> >>>> The current specification allows cost maps to convey only one type of >>>> cost information at a time. It has been pointed out that, in some cases, >>>> applications may benefit from the presence of multiple cost-type values >>>> in a single cost map (see draft-randriamasy-alto-multi-cost for a >>>> detailed description of such use cases) and an extension for allowing >>>> that has been proposed. >>>> >>>> Possible options (please express and possibly motivate your preference): >>>> >>>> 1. allow only one type per cost map in the core protocol >>>> specification and define the syntax and usage of multi-cost maps >>>> as an extension; >>>> >>>> 2. extend the core protocol specification to allow multi-cost >>>> information to be queried and provided in base responses; >>>> >>>> 3. other. >>>> >>> >>> _______________________________________________ >>> alto mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/alto >>> >>> >> >> _______________________________________________ >> alto mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/alto >> > > -- > > --------------------------------------------------------- > Sabine RANDRIAMASY > Alcatel-Lucent Bell Labs France Centre de Villarceau > Route de Villejust - 91620 NOZAY - FRANCE > > E-MAIL : [email protected] > TEL: +33 (0)1 30 77 27 45 (On Net) 2 103 27 45 > --------------------------------------------------------- > > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
