[Opensim-dev] Global identifiers

[Melanie]

The parameter format has ONE advantage: It allows to separate the
fields without needing to make assumptions. However, the presence of
parameters makes the reply uncacheable, as script replies are not
cached by proxies. Therefore, it causes more "across the net" traffic.

In the short run, it won't make so much difference, but years down
the line, with 10000s of sites and millions of users, cachability of
replies is a factor. The extra path info URL can be cached.

Also, my points about mandatory vs. optional still stand. I know
from experience that implementations that don't need a field usually
don't check for it's presence and that client implementors often go
by common usage, rather than standards, for parameters, so this
fosters the development of incompatible implementations.

So, i'm still sort of attached to my original format. With the
current client, the onlly thing that is mandatory is a string to
display. I see no need for additional data at this time.

Also, the display name as extra path info PLUS optional params that
may come later is also possible.

Finally, about the URI schema thing, the /users/ thing is currently
the one that is handled most efficiently in the C# httpd.
Alsp, for caching purposes, the "authority" should be in the path,
so it can work without parameters.

Melanie
Ai Austin wrote:
> At 01:16 30/08/2010, opensim-dev-request at lists.berlios.de wrote:
>> >> protocol://authority/resource_type/resource_id[?key_value_pair[,...]]
> 
> I did of course mean to use "&" between the key-value pairs, not ",".
> 
> Diva I think is suggesting optional extra data beyond the grid name 
> and UUID, melanie I believe is suggesting anything added is 
> compulsory, and that the avatar display name is in that class (as I 
> think most people have also agreed) .
> 
> Either way, things and requirements can change, and there could 
> therefore be different "versions" of such URIs with and without some 
> later field.  Hence my suggestion that it uses a flexible format 
> of  key=value pairs and that we make clear what is expected or 
> required for any given resource_type, , and what is for helpful 
> additional information.
> 
> protocol://authority/resource_type/resource_id?key=value&...
> 
> Perhaps a bit more radical.... I even wonder if the resource_id 
> (and  resource_type?) should be the same (i.e. all key=value 
> pairs).  That way all sorts of CGI and web app lookups would be 
> possible without web server URL mapping.
> 
> protocol://authority/resource_type/?resource_uuid=UUID&key=value&...
> 
> protocol://authority/<root>?resource_type=type&resource_uuid=UUID&key=value&...
> 
> I assume some sensible <root> part of the URI would be needed and 
> others have noted that might help to differentiate incoming service 
> calls for this functionality on the web server component of the 
> OpenSim HTTP listener.  E.g. <root> = id
> 
> While not wanting to open this up even more... hey why not.. its a 
> good discussion...  it would seem that we are wanting a URN 
> (Universal Resource NAME) as we do not want to imply availability of 
> the identity/"name" at a given location. But I think Karen has 
> already been talking along these lines.
> 
> http://en.wikipedia.org/wiki/Uniform_Resource_Name 
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 
>