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