On Mar 15, 2013 3:51 PM, "Richard Alimi" <[email protected]> wrote: > > > On Fri, Mar 15, 2013 at 10:47 AM, Y. Richard Yang <[email protected]> wrote: >> >> >> On Mar 15, 2013 11:35 AM, "Y. Richard Yang" <[email protected]> wrote: >> > >> > >> > Richard A., >> > >> > Thanks a lot for quickly start the discussions right away! Please see below. >> > >> > On Fri, Mar 15, 2013 at 10:47 AM, Richard Alimi <[email protected]> wrote: >> >> >> >> For the IRD, there are a couple of ways we could go. >> >> >> >> [ In the examples, I'll use the proposal where we add "cost metrics"; adjust as necessary depending on the outcome of that discussion. ] >> >> >> >> In the first, we have the cost-types expanded in each of the individual resource entries: >> >> >> >> resources = [ >> >> { >> >> "uri" : "http://alto.example.com/costmap/num/somemaps";, >> >> "media-types" : [ "application/alto-costmap+json" ], >> >> "capabilities" : { >> >> "cost-types" : [ >> >> {"mode" : "numerical", "metric": ”routingcost"}, >> >> {"mode" : "numerical", "metric": ”hopcount"} >> >> ] >> >> } >> >> ] >> >> >> >> >> >> A second way is that we could have a lookup table accompanying the IRD: >> >> >> >> "cost-types": { >> >> "num-routing": {"mode" : "numerical", "metric": ”routingcost"}, >> >> "num-hop": {"mode" : "numerical", "metric": ”hopcount"} >> >> } >> >> >> >> "resources" = [ >> >> { >> >> "uri" : "http://alto.example.com/costmap/num/somemaps";, >> >> "media-types" : [ "application/alto-costmap+json" ], >> >> "capabilities" : { >> >> "cost-types" : [ "num-routing", "num-hop" ] >> >> } >> >> ] >> >> >> >> Some benefits I see to this second approach is that it makes the IRD as a whole more concise when there are multiple cost maps and just generally seems "cleaner" to me. It remains concise if we add more descriptors to a "cost metric" in the future. The identifiers are opaque and local to the IRD so there is no need to register them or even require them to be consistent between IRDs delivered to a client. >> >> >> > For IRD, I like the second approach later as well. We can later extend the fields, such as to have: >> > "num-routing": {"mode" : "numerical", "metric": ”routingcost", "description":"My descriptoin"}, by adding some fields that Wendy suggested. >> > >> > A further step is on individual IR, for example, Cost Map, do we specify "num-routing" or ? >> > {"mode" : "numerical", "metric": ”routingcost"} >> > >> > If we use "num-routing", then the ALTO Client needs to fetch the name from IRD, which may or may not be desirable. >> >> Some possibilities using named model/metric in individual IR >> >> - give a pointer (uri or uri to ird) on where the name can be fetched >> >> - define the name again in the individual IR but this may not be too useful to define a variable that will be used only once. >> >> Any other possibility? > > I would tend to prefer just stating the cost metric and the cost mode directly in the individual IR. The major reason is that it reduces coupling between the entity providing the IR and the entity providing the initial IRD. For example, if the IR were static content hosted somewhere, then it doesn't even have to be updated when scheme for creating this identifier in the IRD is changed. Furthermore, its possible for multiple IRDs to point to a single IR and they don't even have to have the same scheme for generating these identifiers. > > In general, I don't see a reason for the IR and the IRD to be coupled (other than saving a few bytes in the IR itself, which I don't think is going to matter). >
I agree with this design: Named in IRD and unnamed in individual IR so no linking to IRD, for now, unless we see new uses that benefit from using a cost type dictionary in individual IR. We can hear if there are other opinions. How about if no objection by Monday, we start to revise this way, as we have cycles next week.Hence, please do comment soon if you feel strongly otherwise. Of course there are comments opportunities after the revisions, but we can start revision as soon as possible. What do you think? Richard > Thanks, > Rich >> >> Richard >> >> > But overall, I support putting "mode" and "metric" into a single object for ease of enumeration. Otherwise, I am flexible. >> > >> > Richard >> > >> > >> >> >> >> Thanks, >> >> Rich >> >> >> >> _______________________________________________ >> >> alto mailing list >> >> [email protected] >> >> https://www.ietf.org/mailman/listinfo/alto >> >> >> > > >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
