if you're relying on an external cache, why do you need to store the same information in the url?
On Tue, Aug 31, 2010 at 1:05 PM, Melanie <mela...@t-data.com> wrote: > 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, <d...@metaverseink.com> 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: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- > >>>> boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com > >>>> Sent: Monday, August 30, 2010 3:39 PM > >>>> To: opensim-dev@lists.berlios.de > >>>> 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: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- > >>>>>> boun...@lists.berlios.de] On Behalf Of Melanie > >>>>>> Sent: Monday, August 30, 2010 2:30 PM > >>>>>> To: opensim-dev@lists.berlios.de > >>>>>> 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, d...@metaverseink.com 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 > >>>>>>> Opensim-dev@lists.berlios.de > >>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>> Opensim-dev mailing list > >>>>>> Opensim-dev@lists.berlios.de > >>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>>>>> > >>>>> _______________________________________________ > >>>>> Opensim-dev mailing list > >>>>> Opensim-dev@lists.berlios.de > >>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>>>> > >>>>> _______________________________________________ > >>>> Opensim-dev mailing list > >>>> Opensim-dev@lists.berlios.de > >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>>> > >>> _______________________________________________ > >>> Opensim-dev mailing list > >>> Opensim-dev@lists.berlios.de > >>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> > >>> _______________________________________________ > >> Opensim-dev mailing list > >> Opensim-dev@lists.berlios.de > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev@lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev >
_______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
