On Mon, Jul 1, 2013 at 11:37 PM, Ben Niven-Jenkins <[email protected]>wrote:
> Richard, > > > On Mon, Jul 1, 2013 at 4:01 PM, Ben Niven-Jenkins < > [email protected]> wrote: > > > Unless there are objections, I'll do the following: > > > (1) Give each Information Resource an 'id' attribute which is a UUID > > > (2) Define the 'refers-to' attribute which identifies the Information > Resource on which it depends by its UUID > > > (3) Define Version Tag to be: > > > object { > > > JSONString id; // UUID of the network map > > > JSONString tag; // opaque identifier that changes with the > version (as we have today) > > > } VersionTag; > > > > > > How does this sound? > > > > BN:Why do we have to force a UUID? What value does that add? An opaque > sequence of bytes (restrict it to string if you like) is sufficient IMO as > the only think you are using it for is comparison. A string would allow > alto maps to be named & configured easily by humans. > > > > > > RY:For comparison to be effective, we need some kind of uniqueness of > the ID, and uniqueness of ID should be defined in a domain (name space, > scope). UUID implies uniqueness globally, in any name space, and hence > unique in each specific domain. > > My understanding is that you feel that this might be a too strong > sufficient condition. In which scope should the opaque map id be unique > then? URI, DNS names are the potential name space that comes to mind to > define a scope. > > We don't need to ensure global uniqueness IMO, all that is required is all > components that generate a particular network map and associated cost map > use a consistent name/identifier. Even with UUIDs there needs to be a level > of co-ordination between the different components to ensure they use the > same UUID. If we use an opaque string there is nothing to stop folks using > UUIDs as their names, we're just not forcing folks to do that which leaves > flexibility to enable scenarios where UUIDs may be cumbersome. > I'm fine with just relaxing it to be an opaque ID. I used UUID out of simplicity, but I agree it doesn't need to be globally unique. > > > > On 1 Jul 2013, at 19:34, Y. Richard Yang wrote: > > > A quick question on a potential scenario. Suppose a client fetches a > cost map (say costmapserver.alto.example.com), and hence obtains the UUID > of the network map. How does the client map the UUID to where to fetch the > network map, which might be hosted at networkmap.alto.example.com? > > > > To be useful you'd have to list the map name as part of the IRD entry > for the network & cost maps. > > > > > > So it will be an item defined in "meta" of the IRD. Similar to current > "cost-types", which defines mapping of names to cost types, this mapping > will be from network map name/ID to URI. Is this what you have in mind? > > Basically, yes. > I was thinking something simpler (without the need for another lookup table) - for each resource entry, we just add an 'id' attribute. > > > The disadvantage is that the design in -16 has only one-way links, from > IRD to individual resources only. Individual resources cannot use the > cost-type names defined in IRD. Hence, a client can work, even without > knowing the IRD. Imagine that IRD is hosted on a meta-data server, and > individual resources are hosted on data servers. Then, if the meta-server > is down, the client using -16 can still proceed. The new dependency on IRD > to provide the mapping then requires that we provide a mechanism so that a > client can always find the IRD, and the IRD server is always available. > Will this be a problem or we feel comfortable with it? > > I'm not sure I see the problem. The IRD contains the map-name/id in the > entries for the network-map and cost-map. The cost map and the network map > both contain the network maps's name and the vtag. > > If the IRD is unavailable/nonexistent the client must have got the URIs > for the network & cost map from somewhere and it can compare the names & > vtags. > I'd agree with Ben here. The ALTO Client must have the URIs for the individual maps in this case (presumably from the IRD), and it would have retrieved the IDs for those maps in that same IRD. It should be able to rely on cached information here, right? Rich > > Ben > >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
