On Mon, Jul 1, 2013 at 4:01 PM, Ben Niven-Jenkins <[email protected]>wrote:
> Rich & Richard, > > > > On Mon, Jul 1, 2013 at 11:29 AM, Richard Alimi <[email protected]> > wrote: > > Thinking about this some more, even changing the Version Tag to have a > unique name (e.g., a UUID) instead of the Network Map URI would be quite a > bit cleaner. > > > > 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? > > 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. > > 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. > 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? 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? Richard > Ben > >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
