Again, I can only say I'm STRONGLY in favor of having the display name option. First, I may WANT the point of origin information, rather than the current identity, as I may need to follow up a lead on the original creator in copyright litigation.
Second, I may not WANT my grid to be forced to make external lookups. So, I stand by my original proposal. Incidentally, that proposal doesn't close off any other avenues, whereas omitting the display name would close off those directions. Melanie Hurliman, John wrote: >> -----Original Message----- >> From: [email protected] [mailto:opensim-dev- >> [email protected]] On Behalf Of Melanie >> Sent: Monday, August 30, 2010 1:09 PM >> To: [email protected] >> Cc: [email protected] >> Subject: Re: [Opensim-dev] Global identifiers >> >> Hi, >> >> Hurliman, John wrote: >> [...] >> > * A HyperGrid user is teleporting from grid A to grid B. Does grid B >> have enough information to build the global identifier "gridA/user"? >> >> They may not teleport in from their home grid. Also, they may be >> carrying objects from other creators, that may have passed through >> any number of grids, any number of which may not exist anymore. >> > > This is a good argument in support of fetching information from the most > recent grid containing an identity instead of trying to go back to a point of > origin. By embedding metadata like a display name in a URL/URN this is > effectively what you are doing, we're just talking about what the on-the-wire > format looks like at that point. I don't have any strong preference about how > global identities are passed around between foreign grids and through export > formats. > >> > * A HyperGrid user rezzes an object into grid B that exists in their >> inventory on grid A. The object has a creator that is unrecognized to >> grid B. Should grid B pull the creator profile from grid A (which may >> actually be storing a local copy of the real creator identity from grid >> X)? Note that this isn't a question about trust because we're already >> trusting grid A to provide creator information for the object, it's >> just about where we pull profile info from. >> >> Grid X may no longer exist. That is why I am so strongly for having >> enough information contained in the URL to be able to at least >> display a name, and, for performance reasons, do no lookups at all >> unless the request is for more than name display (e.g. communication). >> > > It sounds like we are on the same page for everything, there's just the > question of how to represent global identities coming into a grid before they > are translated into a local identity. I'll defer to the expertise of others > here. I'm generally more in favor of using URLs (even if they are non-opaque) > instead of a new URN format. If a grid only cares about storing the display > name in the profile and is happy to leave the rest of the profile data blank > then no request would be needed at all here, it can just create the local > account with a new UUID and the given name and continue on. > >> > * An OAR file is loaded and contains an unrecognized identity. Should >> identities in OAR files be encoded as global identifiers, or a header >> added to the OAR file to say "all of this content came from grid A", or >> the full profiles of all the identities in the OAR embedded right into >> the archive? >> >> Oar and Iar should always translate the identifiers to global >> format, and may be written to translate loaded data back to local >> format if it originated with the grid loaded into. >> >> > >> > P.S. I'm CCing this to the VWRAP list as the participants there will >> be interested in how these architecture decisions are progressing in >> OpenSim, and may be able to lend more insight to the discussion. >> > >> > -John >> > >> > >> >> -----Original Message----- >> >> From: [email protected] [mailto:opensim-dev- >> >> [email protected]] On Behalf Of [email protected] >> >> Sent: Monday, August 30, 2010 9:34 AM >> >> To: [email protected] >> >> Subject: Re: [Opensim-dev] Global identifiers >> >> >> >> Let me throw another thought into this. It is related to the subtle >> >> differences of URLs and URNs, and Bob Wellman's suggestion. >> >> >> >> So far we are more or less converging to >> >> protocol://authority/resource_type/resource_id[/cacheable_info] >> >> with the [/cacheable_info] sill up for discussion. Independent on >> how >> >> you break this down in persistent storage, this is an URL, and one >> with >> >> specific assumptions about the existence of a resource_id. >> >> >> >> However, in the future we would like to interoperate with systems >> that >> >> aren't virtual worlds as such. In most of those systems, the >> resources >> >> are named with names that may not even be URLs and even if they are, >> >> they may not have "resource_id" at all. For example, >> >> >> >> Cristiano Ronaldo's Facebook handle is >> >> http://www.facebook.com/Cristiano >> >> >> >> A Collada model has >> >> <contributor><author>John.Smith</author></contributor> >> >> (Wondering how Linden Lab is going to deal with this... ) >> >> >> >> >> >> So this would not comply with the form above. >> >> >> >> Now, in practice, we have been designing under a fixed-point: the LL >> >> viewer. The LL viewer MUST have UUIDs for every resource that is >> sent >> >> from the server the client. So, in practice what this means is that >> >> every external resource reference must be assigned a local UUID if >> it >> >> doesn't come with one, which sounds like a very reasonable thing to >> do, >> >> and some people here already mentioned it. >> >> >> >> Nevertheless, the Collada example breaks the assumption that every >> >> named >> >> resource out there has an authority (locator) that we can refer back >> >> to. >> >> It may not. We can continue down the road of fixing missing >> information >> >> with default information. So, for example, if something comes in as >> >> John.Smith, our reference to it could be >> >> http://ourgrid/user/some_uuid/John+Smith -- even though there is no >> >> such >> >> account. But that's a slippery slope. >> >> >> >> This further supports the argument of having a table that maps >> between >> >> local UUIDs and external references. And maybe external references >> may >> >> take more than just one URI form, not just the one we have been >> talking >> >> about >> >> protocol://authority/resource_type/resource_id[/cacheable_info] >> >> >> >> Maybe it can also be a URN. >> >> >> >> Nevertheless, the semantics is important, because when an authority >> >> (locator) is present, the receiving grid may want to invoke it. >> >> >> >> >> >> >> >> Melanie wrote: >> >> > While you have a case with using a central table, rather than >> >> > storing the URL string, and therefore the name, all over the >> place, >> >> > your request schema would not work. >> >> > >> >> > First off, it overcomplicates (IMO) things if you even attempt to >> >> > show the current name of an identity. My plan has been to show the >> >> > name AT CREATION TIME on a prim, e.g. the displyed creator name of >> a >> >> > prim will not change, even if the underlying identity changes >> their >> >> > name. This removes much complaxity. >> >> > >> >> > Second, your system breaks when a prim is taken to a new grid >> after >> >> > the grid it was created on has vanished from the internet. In that >> >> > case, even the initial lookup will fail and you have no data to >> >> display. >> >> > >> >> > Therefore, I'd prefer to go with my initial recommendation and >> >> > indeed store the URL, including the name, "all over the place". >> The >> >> > client view can always decide to ignore that part and to a table >> >> > lookup, or even contact the grid of origin. >> >> > >> >> > It seems that a lot of people here are all for omitting >> information >> >> > that would be helpful for the 90% case in order to make their >> >> > particular corner case the norm. 90% of avatars never change >> names. >> >> > >> >> > Melanie >> >> > >> >> > Bob Wellman wrote: >> >> >> 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 >> >> > _______________________________________________ >> >> > 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
