I'm not relying on one. I'm imagining a world where VW traffic is the main part of internet traffic, having displaced the flatweb. For ISP caching, it's important that most protocols are designed to be RESTful. I don't plan on caching, but i don't want to create a protocol that is inherently uncacheable. Be nice to the net.
Melanie Dahlia Trimble wrote: > 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 _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
