<br><font size=2 face="sans-serif">I think the admin prefix is important,
though the spelling may change. With Open Sim we</font>
<br><font size=2 face="sans-serif">need to be able to partition the resource
name spaces so that arbitrary REST-based</font>
<br><font size=2 face="sans-serif">services can be implemented without
conflict. Don't we? If we don;t then I think we can all</font>
<br><font size=2 face="sans-serif">look forward to those interminable debates
that inevitable arise once any kind of naming</font>
<br><font size=2 face="sans-serif">or data organization scheme is enforced.
It does remain true though, that once adopted,</font>
<br><font size=2 face="sans-serif">a higher level prefix should have a
recognized signficance.</font>
<br>
<br><font size=2 face="sans-serif">Currently the prefix values used to
match for existing stream handlers are scattered ad hoc</font>
<br><font size=2 face="sans-serif">throught he source tree. I think there
is a need for a single defining class for these strings.</font>
<br><font size=2 face="sans-serif">If we carry this through to its natural
conclusion I think we end up with the sort of REST </font>
<br><font size=2 face="sans-serif">manager that Dirk was thinking about
originally.</font>
<br>
<br><font size=2 face="sans-serif">I agree that we should use the HTTP
message semantics to our maximum advantage.</font>
<br><font size=2 face="sans-serif">The idea of flattening the URI tree
with redirects is a nice one.</font>
<br>
<br><font size=2 face="sans-serif">Could we use tagging to select the attributes
we really want when we're retriving actual</font>
<br><font size=2 face="sans-serif">data about a resource such as a region?</font>
<br>
<br><font size=2 face="sans-serif">Should all this be done at a server
level? It seems like this stuff has the same functional</font>
<br><font size=2 face="sans-serif">relationship to a server as some of
the other servers that have been broken out so they</font>
<br><font size=2 face="sans-serif">have a one-to-many region relationship
regardless of server topology (grid or s/a). This</font>
<br><font size=2 face="sans-serif">seems like one more service that should
be broken out and be handled in the same way.</font>
<br><font size=2 face="sans-serif">Perhaps the grid server is a proxy variation
on a server specific theme?</font>
<br><font size=2 face="sans-serif"><br>
Best regards<br>
Alan<br>
-------------------<br>
T.J. Watson Research Center, Hawthorne, NY<br>
1-914-784-7286<br>
alan_webb@us.ibm.com</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Dr Scofield <DrScofield@xyzzyxyzzy.net></b>
</font>
<br><font size=1 face="sans-serif">Sent by: opensim-dev-bounces@lists.berlios.de</font>
<p><font size=1 face="sans-serif">05/14/2008 10:47 AM</font>
<table border>
<tr valign=top>
<td bgcolor=white>
<div align=center><font size=1 face="sans-serif">Please respond to<br>
opensim-dev@lists.berlios.de</font></div></table>
<br>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">opensim-dev@lists.berlios.de</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: [Opensim-dev] RFC: RESTful dealings
with regions</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2>Sean Dague wrote:<br>
> On Tue, May 13, 2008 at 08:09:54PM +0200, Dr Scofield wrote:<br>
>   <br>
>> we are currently trying to figure out what the best approach for
a REST <br>
>> "API" for regions is and would like to solicit comments
:-)<br>
>><br>
>> currently the idea is to have a scheme as follows:<br>
>><br>
>>     * http://opensim.foobar.org:9000/admin/regions ---<br>
>>           o GET returns an array of (UUID,
name, x location, y location,<br>
>>             region's REST URL)<br>
>>     <br>
>                  
   I think this should just return UUIDs  Let's not overload<br>
>                  
   the list functionality with the actual data, as it may get<br>
>                  
   you much more than you care about.<br>
>   <br>
yeah...was wondering about that. so we'd return region URL with is <br>
/regions/UUID, agree?<br>
>   <br>
>>           o POST would create a region<br>
>>     * http://opensim.foobar.org:9000/admin/regions/4b787c46-1e3c-40ae-9494-2c924428f8e5/<br>
>>           o GET would return detailed
information about region<br>
>>           o DELETE would delete region<br>
>>           o PUT would update region information<br>
>>     * http://opensim.foobar.org:9000/admin/regions/4b787c46-1e3c-40ae-9494-2c924428f8e5/name<br>
>>           o GET would return name of
region<br>
>>           o PUT would update name of
region<br>
>>           o [similar for other region
attributes if it makes sense]<br>
>>     <br>
><br>
> +1, I like all of that.  My only question is really why have
the /admin<br>
> at all.<br>
>   <br>
just wanted to avoid clashing with anything else...actually it currently
<br>
is configurable :-)<br>
>   <br>
>> current planning is to have this as an ApplicationPlugin level
set of <br>
>> RestPlugins. an alternative would be to use region modules plus
an <br>
>> ApplicationPlugin (for GET/POST on /admin/regions).<br>
>><br>
>> this applies to region (meta) data. the next question would be
how to <br>
>> structure this for avatar information and also for stuff like
inventory: <br>
>> something along the lines below?<br>
>><br>
>>     * http://opensim.foobar.org/admin/avatars<br>
>>           o GET returns list of known
avatars?<br>
>>           o POST creates account?<br>
>>     <br>
><br>
> I think the right resource name here is "users" instead
of "avatars"<br>
>   <br>
ok.<br>
>   <br>
>>     * http://opensim.foobar.org/admin/avatars/430f1da7-0e35-4c0f-985d-15046c077967/<br>
>>           o GET returns detailed information
about avatar?<br>
>>           o PUT updates?<br>
>>           o DELETE deletes?<br>
>>     * http://opensim.foobar.org/admin/avatars/430f1da7-0e35-4c0f-985d-15046c077967/inventory/<br>
>>           o GET returns inventory listing?<br>
>>           o POST adds items to inventory?<br>
>>           o DELETE deletes inventory
items?<br>
>>     <br>
><br>
> I think that as we dig into users -> inventory what we'll actually
get<br>
> is.<br>
><br>
> /admin/avatars/430f1da7-0e35-4c0f-985d-15046c077967/inventory/ =>
302 =><br>
> /admin/inventory/XXXX-...<br>
><br>
> Which takes us into an inventory resource tree.  Remember, in
using REST<br>
> and HTTP you get to use all the HTTP semantics including all the 30x<br>
> redirects.<br>
>   <br>
nice!<br>
<br>
thx for the feedback!<br>
<br>
    cheers,<br>
    dr scofield/dirk<br>
<br>
-- <br>
dr dirk husemann, mathmatics and computer science, ibm zurich research
lab<br>
SL: dr scofield ---- drscofield@xyzzyxyzzy.net ---- http://xyzzyxyzzy.net/<br>
RL: hud@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/<br>
<br>
_______________________________________________<br>
Opensim-dev mailing list<br>
Opensim-dev@lists.berlios.de<br>
https://lists.berlios.de/mailman/listinfo/opensim-dev<br>
</font></tt>
<br>