Can I subvert this discussion back to the original question of Global Identifiers?
I have been following the discussion on Global Identifiers with interest and I see strong differences of opinion but merits in both arguments. I agree that hard coding meaning into the URI seems like an inflexible way forward but I also see that minimising lookup traffic between grids is desirable too. So I have been trying to think is there a middle way to compromise on this. I have the kernel of an idea I would like to put forward for discussion. Let us say we invent a new table in the local grids database (called UserLookup maybe) and the key to that table is the URI diva proposed (without the user name part) sent intially. Sorry Melanie but please read on before deciding. Draft table design here: 1) Original URI (key) 2) Original User name 3) Last verification date. 4) Current user name 5) Current URI (optional idea see later) When the original URI is received (or later referenced) we do a check against this table to see if a lookup is available and proceed as follows: 1) If the lookup is not on file… we immediately send to the other grid for verification and the user name and we add the lookup to the table with original user name and current user name the same. 2) If the lookup is on file but out of date … we send to the other grid for verification (this can be dleayed if need be) and take the latest feedback of user name and update the lookup with current name. 3) If the lookup is on file but not out of date (most times this will be the case) … we do nothing. What constitutes out of date will be configurable in Opensim.ini (out-of-date= x days). In Melanie’s case she will set forever as avatars must not be changeable. For others this can be tailored to their requirements of speed versus flexibility. The user service already looks up the Prims user UUID to decode the name for local avatars so it just would be changed to do this new lookup at the same time. I think of it this way …The user service currently answer the question “who is this” and would now answer “who in the global community is this”. This method keeps the database design 3rd normal form rather than storing key decodes all over the database, as to not do this will at some stage cause database chaos just like it did in appearance sometime ago. Can you tell I have a database design background...LOL If a grid goes bust or is temporary offline we have the last know user info to rely on using just local grid lookup, which covers the very valid argument Melanie made that we need to know identity even if the other grids no longer there. We can also have the ability to recognise that verification has not been available for a long time so cross grid IM is probably no longer available to this agent. In the case of an avatar moving grid maybe the forwarding address can be sent back and the current URI stored (the fifth column) at the next look up verification. If the forwarding doesnt ecist or is only temporary, it does matter, as we have last known address stored at our grid, which is the best thats possible. Maintaining an IM link of freindship to an agent that moves grids becomes feasible too. So this keeps things flexible for those that think this is the correct approach long term. In summary this method reduces the need for massive cross grid lookups and still keeps the link between the URI and the user name flexible. Just my opinion (and I expect to be overruled) but felt I should say this anyway if only to purge my guilt of saying nothing just to avoid a slap down …LOL Thanks for reading it.. Bob Wellman (PMgrid) > Date: Sun, 29 Aug 2010 19:59:34 -0700 > From: [email protected] > To: [email protected] > Subject: Re: [Opensim-dev] Global identifiers > > See my previous email about what changed. > > We seem to have quite different concepts of what a standards process is. > In my book, a standards process is something that happens *after* > implementations exist, and preferably several competing ones; in the > people in VWRAP's book, it seems to mean "let's design something > together from scratch and on paper". > > Let's see how well these two concepts can co-exist. Maybe they can't! > > Meadhbh Hamrick wrote: > > what's changed? > > > > last year you (diva) seemed to have no interest in merging VWRAP with > > Hypergrid. if i remember correctly, hypergrid was going to go off and > > do an implementation while VWRAP went another way to try to > > incrementally build a standard and some code to implement it. > > > > there's still, of course, room for you at the table. but if i remember > > correctly, you seemed to have problems with LLSD/LLIDL (now about to > > get renamed DSD) and you had a security model that didn't work with > > zha's use cases. > > > > if you're interested in making the case for why VWRAP should adopt the > > hypergrid security model and drop DSD, you're welcome to participate > > in the VWRAP mailing list. > > > > and i encourage you to actually do so before dropping a spec on the group. > > > > -cheers > > -meadhbh > > > > -- > > meadhbh hamrick * it's pronounced "maeve" > > @OhMeadhbh * http://meadhbh.org/ * [email protected] > > > > > > > > On Sun, Aug 29, 2010 at 5:29 PM, <[email protected]> wrote: > >> Melanie is just right, as usual... well, as in 90% of the time :) > >> The cacheable_data was a brilliant idea, and if you had experience with > >> OpenSim in the wild, in how volatile these worlds are and how much these > >> particular remote lookups lag the sims, you would come to appreciate it, > >> instead of being put off by her dominatrix attitude. > >> > >> OpenSim core has been contributing center-front in VWRAP: John Hurliman is > >> a > >> core developer of OpenSim. > >> > >> Mike Dickson wrote: > >>> That's great to hear. And the first I've heard of it. I'm on the VWRAP > >>> mailing list and yes, John has made some very substantive contributions > >>> to the discussion. I haven't seen anything from OpenSim core during any > >>> part of the discussion to date. I'm a pretty smart guy but not > >>> omnipotent. I've simply interpreted the lack of participation as lack > >>> of interest and past comments would tend to support that (I can dig them > >>> out if you like). And there is no "general feeling" in VWRAP as to your > >>> proposal since its never been presented or discussed there. > >>> > >>> I'm not interested in a war, just open dialog and a sincere interest in > >>> interoperability. I'll be glad to read the proposal when its made. In > >>> the meantime I'd appreciate you not attribute negative motives to > >>> anything I've said. I've been simply trying to make technical arguments > >>> against an approach I think is wrong headed and not though out. I've > >>> seen discussion here pretty much get cut off when a core member > >>> "dictates" the solution. Melanie seems to have made up her mind. Fine. > >>> Go build it. Best of luck to you. In the meantime I'll look forward to > >>> the Hypergrid proposal to VWRAP and reserve my comments for that time. > >>> BTW, I've found the VWRAP discussions to be pretty open and devoid of > >>> politics. People will assert politics over almost anything of course > >>> but the dialog has been mostly open and good natured (and quiet lately). > >>> It will be good to have you at the table. Given OpenSim gets a fair bit > >>> of attention it would have been nice if you'd been there all along. > >>> > >>> Mike > >>> > >>> On Mon, 2010-08-30 at 00:00 +0000, [email protected] wrote: > >>>> Mike, > >>>> > >>>> That's an interesting statement to make, considering that John Hurliman > >>>> and I are working on writing up the *working* Hypergrid 1.5 as a > >>>> proposal to > >>>> VWRAP, since we have both concluded that the concepts being talked there > >>>> lately, without any implementation behind them, are essentially > >>>> indistinguishable from the working HG 1.5 that lots of people are already > >>>> using. > >>>> > >>>> It seems that you are trying really hard to make this look like a war > >>>> between OpenSimulator and VWRAP. I don't think that's the general > >>>> feeling in > >>>> VWRAP, I think it's just you. The proposal to VWRAP will happen. > >>>> Hopefully, > >>>> most people there will be able to assess the technical issues, > >>>> independent > >>>> of the political ones. (emphasis on *hopefully*) > >>>> > >>>> Diva / Crista > >>>> > >>>> Mike Dickson wrote: > >>>>> Fine, then do what you like. The code's all available. If I don't like > >>>>> it I can change it. Of course that sort of shoots holes in > >>>>> interoperability. But then I didn't feel that hyper-grid belonged in > >>>>> core either for the same reason. > >>>>> I think you've way over trivialized the whole set of interactions > >>>>> between agent, asset and simulator services in situations where those > >>>>> services are defined by different principals. As Meadbh said, this > >>>>> feels like optimizing to solve a specific problem before you've really > >>>>> looked at the larger issues. It might be instructive just to simply walk > >>>>> through some use cases and see where things fall apart. Alot of that > >>>>> discussion has already taken place on the VWRAP list but OpenSim core > >>>>> seems to be dead set against involvement in that. > >>>>> > >>>>> I don't see a way to contribute here beyond the opinion I've already > >>>>> voiced so I'll drop this. > >>>>> > >>>>> Mike > >>>>> > >>>>> On Sun, 2010-08-29 at 22:56 +0000, Melanie wrote: > >>>>>> Sorry, i disagree. The information included is defined by the > >>>>>> REQUIRED data on the recipient, not on what data the sender wants to > >>>>>> provide. the recipient NEEDS a displayable field. It can't be optional. > >>>>>> > >>>>>> Melanie > >>>>>> > >>>>>> Mike Dickson wrote: > >>>>>>> If the decision is to go ahead and do cache-able data then I'd agree, > >>>>>>> do > >>>>>>> it as attribute NVP's and make them optional. The originating agennt > >>>>>>> service is then free to define the semantics of the attributes it > >>>>>>> exposes. > >>>>>>> Mike > >>>>>>> > >>>>>>> On Sun, 2010-08-29 at 21:42 +0000, Ai Austin wrote: > >>>>>>>>> From: [email protected] > >>>>>>>>> protocol://authority/resource_type/resource_id[/cacheable_data] > >>>>>>>> +1 > >>>>>>>> > >>>>>>>> consider ensuring that at least the name is provided in a form that > >>>>>>>> can be resolved fast and locally by including the avatar > >>>>>>>> firstname+lastname > >>>>>>>> - in whatever form the providing grid wishes to address issues > >>>>>>>> raised by > >>>>>>>> others - so long as the strings are "legal" in the creator/owner > >>>>>>>> fields. > >>>>>>>> > >>>>>>>> would it be worth making sure that the "cachable data" is in the form > >>>>>>>> of keyword=value pairs, and hence put in a "parameter" form after ? > >>>>>>>> rather > >>>>>>>> than a final /? > >>>>>>>> > >>>>>>>> protocol://authority/resource_type/resource_id[?key_value_pair[,...]] > >>>>>>>> > >>>>>>>> with a minimum suggested (or required?) > >>>>>>>> avatarname=firstname+lastname if the resource_type = user > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> 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
