if you're relying on an external cache, why do you need to store the same information in the url? <br><br><div class="gmail_quote">On Tue, Aug 31, 2010 at 1:05 PM, Melanie <span dir="ltr"><<a href="mailto:melanie@t-data.com">melanie@t-data.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">See my prior messages. That format is inherently un-cacheable. I<br>
believe the mandatory info needs to be part of a URL that can be<br>
fetched with GET and cached, e.g. is RESTful.<br>
<font color="#888888"><br>
Melanie<br>
</font><div><div></div><div class="h5"><br>
Dahlia Trimble wrote:<br>
> I've tried to use extra information in URLs before by slash-delimiting them<br>
> and all seemed to work well until I ran into situations such as missing data<br>
> for one of the terms and some URL parsers did not accept the double slash<br>
> which resulted from the missing field. Another problem exists when extending<br>
> the definition at a later date, then all parsers that have to deal with the<br>
> URL have to be modified. After banging my head over these kind if issues I<br>
> went back and redesigned it to use the &name=value format and I''ve never<br>
> regretted it since. Parsing it is quite simple in C# with String.Split()<br>
><br>
> Given the open source nature of OpenSimulator, I would think diverging<br>
> definitions would be unavoidable and would likely hinder interoperability<br>
> unless some means for allowing flexibility was designed in from the start,<br>
> and I think name-value pairs are a usable means of providing that<br>
> flexibility.<br>
><br>
><br>
> On Tue, Aug 31, 2010 at 7:53 AM, <<a href="mailto:diva@metaverseink.com">diva@metaverseink.com</a>> wrote:<br>
><br>
>> Hurliman, John wrote:<br>
>><br>
>>> It sounds like the decision has been made (or was already made before this<br>
>>> discussion started), so on to the next step. Can you (Melanie or Diva) do<br>
>>> these two things?<br>
>>><br>
>><br>
>> As I said, the issue was *really* narrow :) Even though the interfaces<br>
>> already account for this, I got scared when I faced the situation of<br>
>> actually creating persistent references to external data. (or, in the case<br>
>> of Simian, creating persistent data structures representing external data,<br>
>> which is similar)<br>
>><br>
>><br>
>> 1) Define exactly how the URL is supposed to be parsed. ABNF notation<br>
>>> would be preferred, or something equivalent that makes it clear what<br>
>>> identifiers are valid or invalid. Or perhaps define any URL as valid like<br>
>>> diva suggested, but only parse display names out of specifically crafted<br>
>>> URLs. With the suggested format of<br>
>>> <a href="http://authority/user/user_id/First+Last" target="_blank">http://authority/user/user_id/First+Last</a> it seems like you would either<br>
>>> assume any URL that includes a space in the last section of the path is<br>
>>> parsed as a first+last name tuple. (I'm assuming you remove any attached<br>
>>> query string before parsing the name.) Or will it look for "user_id" as the<br>
>>> second to last segment of the path followed by a path segment containing a<br>
>>> space? Obviously it can't expect /user/user_id/First+Last to be anchored at<br>
>>> the root of the domain since it won't be possible to generate those URLs on<br>
>>> some setups.<br>
>>><br>
>><br>
>> Yes, and that's the crux of the narrow issue in discussion. So let's finish<br>
>> those little details on the IRC, maybe.<br>
>><br>
>><br>
>> 2) Standardize the handling of external identities in OpenSim. Go through<br>
>>> and clean out the approaches that are no longer being used, such as<br>
>>> OpenSim.Framework.Communications.Osp. I can help with this part as I'm<br>
>>> always a fan of removing dead code.<br>
>>><br>
>><br>
>> That's the only broad consequence of this issue, and one that I also feel<br>
>> it's very important. I know these global names have been used before -- or<br>
>> maybe never used, but the code is there -- and, even though I didn't<br>
>> remember the syntax, I remembered that it looked nothing like an URI.<br>
>> Thanks, Justin, for explaining. If everyone is ok with the URI syntax, then<br>
>> let's make it consistent across the board.<br>
>><br>
>><br>
>><br>
>>> John<br>
>>><br>
>>> -----Original Message-----<br>
>>>> From: <a href="mailto:opensim-dev-bounces@lists.berlios.de">opensim-dev-bounces@lists.berlios.de</a> [mailto:<a href="mailto:opensim-dev-">opensim-dev-</a><br>
>>>> <a href="mailto:bounces@lists.berlios.de">bounces@lists.berlios.de</a>] On Behalf Of <a href="mailto:diva@metaverseink.com">diva@metaverseink.com</a><br>
>>>> Sent: Monday, August 30, 2010 3:39 PM<br>
>>>> To: <a href="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a><br>
>>>> Subject: Re: [Opensim-dev] Global identifiers<br>
>>>><br>
>>>> OK, so here's the form of the URI that will start showing up in the<br>
>>>> [non-Simian] DBs soon, specifically in the GridUser table:<br>
>>>> <a href="http://authority/user/user_id/First+Last" target="_blank">http://authority/user/user_id/First+Last</a><br>
>>>><br>
>>>> Yes?<br>
>>>><br>
>>>> I suspect that SimianGrid will take things like<br>
>>>> LoggedIn(string userID) and<br>
>>>> StoreGridUserInfo(GridUserInfo info)<br>
>>>><br>
>>>> and create user accounts for these if they don't exist, because I think<br>
>>>> SimanGrid collapses the 2 concepts. Just keep in mind that you'll soon<br>
>>>> be receiving URLs of the form above as arguments.<br>
>>>><br>
>>>> I agree with Melanie that not adding the display name is a missed<br>
>>>> opportunity for caching, but I'm willing to write up code that accounts<br>
>>>> for it being optional for all the grid operators who would rather have<br>
>>>> the extra lookups coming their way.<br>
>>>><br>
>>>> Hurliman, John wrote:<br>
>>>><br>
>>>>> If we are still on the same page, there should never be a case where<br>
>>>>><br>
>>>> something could be either a local identifier (UUID) or a global<br>
>>>> identifier (URL). The context is always clear, where cross-grid<br>
>>>> communication and exported content uses only global identifiers and all<br>
>>>> intra-grid communication uses only local identifiers. If a sim wants to<br>
>>>> resolve the creator of a prim it uses a single path, the UUID->Profile<br>
>>>> (aka display name) API call which takes advantage of all the caching<br>
>>>> and optimizations we've built into OpenSim. There is no ambiguity there<br>
>>>> or potential for the code to take a slower or less tested path. The<br>
>>>> discussion is about communication outside of the local grid context,<br>
>>>> when you are exporting content or moving people or content between<br>
>>>> grids. In every use case there I think it makes sense to always use<br>
>>>> global identifiers, or at least a clear path to build a global<br>
>>>> identifier.<br>
>>>><br>
>>>>> John<br>
>>>>><br>
>>>>> -----Original Message-----<br>
>>>>>> From: <a href="mailto:opensim-dev-bounces@lists.berlios.de">opensim-dev-bounces@lists.berlios.de</a> [mailto:<a href="mailto:opensim-dev-">opensim-dev-</a><br>
>>>>>> <a href="mailto:bounces@lists.berlios.de">bounces@lists.berlios.de</a>] On Behalf Of Melanie<br>
>>>>>> Sent: Monday, August 30, 2010 2:30 PM<br>
>>>>>> To: <a href="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a><br>
>>>>>> Subject: Re: [Opensim-dev] Global identifiers<br>
>>>>>><br>
>>>>>> I think we already have a perfectly good field, which is a UUID for<br>
>>>>>> local users and a URL for remote ones.<br>
>>>>>><br>
>>>>>> Melanie<br>
>>>>>><br>
>>>>>> Serendipity Seraph wrote:<br>
>>>>>><br>
>>>>>>> On 8/30/10 2:09 PM, <a href="mailto:diva@metaverseink.com">diva@metaverseink.com</a> wrote:<br>
>>>>>>><br>
>>>>>>>> Hurliman, John wrote:<br>
>>>>>>>><br>
>>>>>>>>> My interpretation (please correct me if I'm wrong) is that there<br>
>>>>>>>>><br>
>>>>>>>> is<br>
>>>><br>
>>>>> rough consensus on the overall strategy, but an open question of<br>
>>>>>>>>><br>
>>>>>>>> how<br>
>>>>>><br>
>>>>>>> to encode global identities when cross-grid communication (or<br>
>>>>>>>>> out-of-grid archiving) happens.<br>
>>>>>>>>><br>
>>>>>>>> That's what's going on.<br>
>>>>>>>> Up to now, all global identifiers (that already exist) have been<br>
>>>>>>>> volatile; nothing has persisted. As I found myself writing code<br>
>>>>>>>><br>
>>>>>>> that<br>
>>>><br>
>>>>> would inject global identifiers into a DB table, I thought we<br>
>>>>>>>><br>
>>>>>>> should<br>
>>>><br>
>>>>> all talk about the form of such identifiers.<br>
>>>>>>>><br>
>>>>>>>> There is probably also a hidden question of how to mark a local<br>
>>>>>>>>> account as linked to a foreign identity, which may solve the<br>
>>>>>>>>> friending issue. If I am friends with your avatar and we are both<br>
>>>>>>>>><br>
>>>>>>>> on<br>
>>>>>><br>
>>>>>>> grid B but your avatar actually originated from grid A, that link<br>
>>>>>>>>><br>
>>>>>>>> in<br>
>>>>>><br>
>>>>>>> the profile is what can tip off the presence service to try a<br>
>>>>>>>>><br>
>>>>>>>> remote<br>
>>>>>><br>
>>>>>>> presence check (assuming the user is not online in the local<br>
>>>>>>>>><br>
>>>>>>>> grid).<br>
>>>><br>
>>>>> My only interest in these low level questions like how the global<br>
>>>>>>>>> identifiers and profile links look is what the final decision is<br>
>>>>>>>>><br>
>>>>>>>> so<br>
>>>><br>
>>>>> I<br>
>>>>>><br>
>>>>>>> can implement it in the OpenSim SimianGrid connectors.<br>
>>>>>>>>><br>
>>>>>>>> Well, we distinguish "user accounts" from "grid users" -- these<br>
>>>>>>>><br>
>>>>>>> are<br>
>>>><br>
>>>>> 2<br>
>>>>>><br>
>>>>>>> different interfaces, although implementers may decide to collapse<br>
>>>>>>>> them. But they are different concepts. User accounts are the<br>
>>>>>>>> locally-registered users; in some cases, like for example, the UCI<br>
>>>>>>>> grid, there's only some people who can get accounts there, namely<br>
>>>>>>>> people associated with the university. Grid users are users that<br>
>>>>>>>><br>
>>>>>>> are<br>
>>>><br>
>>>>> referenced by things that happen in the grid. So we already have<br>
>>>>>>>><br>
>>>>>>> an<br>
>>>><br>
>>>>> interface for that, although now I'm thinking that perhaps we need<br>
>>>>>>>><br>
>>>>>>> to<br>
>>>>>><br>
>>>>>>> separate its UserID field into 2 things: a local UUID and a<br>
>>>>>>>><br>
>>>>>>> reference<br>
>>>>>><br>
>>>>>>> to the external name. And I guess that's my main issue at this<br>
>>>>>>>><br>
>>>>>>> point.<br>
>>>>>><br>
>>>>>>> It seems more reasonable in a distributed system to say that an X<br>
>>>>>>><br>
>>>>>> is<br>
>>>><br>
>>>>> an<br>
>>>>>><br>
>>>>>>> X - a User is a User, whether they originally were instantiated on<br>
>>>>>>><br>
>>>>>> a<br>
>>>><br>
>>>>> local or a remote system. So I would go for collapsing the two as<br>
>>>>>>><br>
>>>>>> much<br>
>>>>>><br>
>>>>>>> as possible as a matter of policy. Otherwise freedom to move<br>
>>>>>>><br>
>>>>>> between<br>
>>>><br>
>>>>> nodes in the system is more limited and there is more special case<br>
>>>>>>><br>
>>>>>> logic<br>
>>>>>><br>
>>>>>>> to deal with. But that is speaking from a general distributed<br>
>>>>>>> computing perspective. There may be many Opensim details that make<br>
>>>>>>><br>
>>>>>> that<br>
>>>>>><br>
>>>>>>> seemingly ideal position in practice rather naive.<br>
>>>>>>><br>
>>>>>>> - s<br>
>>>>>>><br>
>>>>>>> _______________________________________________<br>
>>>>>>> Opensim-dev mailing list<br>
>>>>>>> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
>>>>>>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> _______________________________________________<br>
>>>>>> Opensim-dev mailing list<br>
>>>>>> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
>>>>>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>>>>>><br>
>>>>> _______________________________________________<br>
>>>>> Opensim-dev mailing list<br>
>>>>> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
>>>>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>> Opensim-dev mailing list<br>
>>>> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
>>>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>>>><br>
>>> _______________________________________________<br>
>>> Opensim-dev mailing list<br>
>>> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
>>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>>><br>
>>> _______________________________________________<br>
>> Opensim-dev mailing list<br>
>> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>><br>
><br>
><br>
</div></div>> ------------------------------------------------------------------------<br>
<div><div></div><div class="h5">><br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</div></div></blockquote></div><br>