The concept is that OBJECTS require no authority. They exist apart from it, which is why their data needs to be self-contained. Objects are reflected as point-in-time of their creation.
The further uses are for communication, e.g. contacting a creator. This may succeed or fail. I believe a grid should not look up anything just to render an object, or provide object properties. Melanie Karen Palen wrote: > I agree that hypergrid does not introduce any new concerns over what we see > in ordinary web pages. However that leaves a lot of room for problems! > > My concern is that we are storing those "web pages" in a database and making > decisions based on that information. I see the potential for the data to > simply degrade over time as more and more references become "bad" in one way > or another. > > Maybe I have missed something, but I have not seen any discussion of how > issues of stale or misguided references are to be handled! > > Do we just accept that over time our "authorities" will disappear? What does > that imply for the objects which depend on those authorities? > > If the "authority" can simply disappear with no effect, then why bother > recording it at all? A simple UUID would serve the same purpose - globally > as well as locally. > > My understanding is that we DO use the "authority" for various things beyond > simple identification. Authentication, updating of information, and DRM > management come to mind. > > This may or may not be an issue, but I think we need to examine the > possibilities and implications carefully. > > Karen > > On Tue, Aug 31, 2010 at 9:30 AM, <[email protected]> wrote: > >> Domain names that existed before cease to exist, and domain name transfers >> happen. This doesn't affect the Hypergrid only, it affects the entire >> Internet. As much as I would like to think that we are smarter than everyone >> else who has been designing and improving the Internet architecture for the >> past 40 years, I think we need to consider the possibility that we aren't >> smarter, and so we probably are not going to solve the general issue of >> stale, or otherwise misguided, references on the Internet... >> >> Karen Palen wrote: >> >>> The problem arises when the original URL no longer exists and one must >>> attempt to find the new authority somehow. >>> >>> Unless of course we are willing to accept that the URL/UUID merely >>> reflects a "point in time". >>> >>> Even then we get a problem if http://XYZ.com goes away and some time >>> (years) later a NEW http://XYZ.com appears and starts doing business on >>> the hypergrid. The new owner of the URL may or may not have any affiliation >>> with the old one. >>> >>> Karen >>> >>> On Tue, Aug 31, 2010 at 6:01 AM, Melanie <[email protected] <mailto: >>> [email protected]>> wrote: >>> >>> This isn't an issue, the URL includes the authority, so no malicious >>> collisions are possible unless the UUID is used in isolation. That >>> should not be done. If a resource is to be used in a contect where a >>> local identifier is required, a new UUID should be generated and >>> attached to the URI, then that should be used. Never trust the UUID >>> in the URI for anything but calling the URI itself. >>> >>> Melanie >>> >>> Karen Palen wrote: >>> > It was buried in another post, but I maintain that the definitive >>> problem is >>> > not th eone where the "authority" simply disappears (wait to >>> update the >>> > cache), but where there are multiple "authorities" claiming the >>> same UUID! >>> > >>> > There are numerous reasons why this could happen, ONE of which is >>> > "malfeasance" (fraud)! >>> > >>> > More likely is the case where the cached "authority" is very much >>> out of >>> > date and there have been several changes since the last cache >>> update! In >>> > some situations this could happen in only a few minutes! >>> > >>> > Every other case resolves to (a) it is in the cache (update >>> whenever we can) >>> > or (b) the (single) authority can tell us what we should use as the >>> > "name"/UUID >>> > >>> > While Diva has pointed out that EVERY "name" is really a UUID >>> (not obvious >>> > in the "global" case) many of the comments imply that the "name" >>> is some >>> > arbitrary text string! >>> > >>> > I claim that Diva is exactly correct - the UUID *IS* the name >>> BOTH global >>> > and local, and the "text string" (of whatever form) is merely the >>> "human >>> > compatible liveware" version. ANYTHING else leads to an enormous >>> number of >>> > identity collisions! >>> > >>> > I think that it is all available in the "open" literature now, >>> but in the >>> > 1960's/1970's the US Military spent an enormous effort ($$$) to >>> be certain >>> > that the person with the badge "General Jack D. Ripper" really >>> WAS that >>> > person! With Nuclear Weapons the stakes really ARE that high! >>> > >>> > Our problem is very similar although not with such dramatic >>> consequences. >>> > >>> > Karen >>> > >>> > On Tue, Aug 31, 2010 at 1:17 AM, Ai Austin >>> <[email protected] <mailto:[email protected]>> wrote: >>> > >>> >> myticaldemina makes a lot of good points... one thing that could be >>> >> problematic though relates to this comment... >>> >> >>> >> From: <[email protected] >>> <mailto:[email protected]>> >>> >>> >>> ...I would suggest any >>> >>> >>> >>> proxies would give the external system and identifier and not >>> chain proxy >>> >>> to >>> >>> proxy unless there is a reason to do it, and the assets should >>> be copied >>> >>> from the original source. >>> >>> >>> >> >>> >> >>> >> I agree with the first half... no chains, just hand over the >>> external >>> >> system "authority" and its given identifier pair for the >>> identity involved. >>> >> >>> >> But I don't agree at all with the idea that you then have to get >>> the asset >>> >> from that original authority. The permissions could have changed, >>> >> corruptions could have occurred or much more likely the >>> authority simply >>> >> will no longer be there. The asset "as is" (with its textures, >>> scripted >>> >> content and what not) should be provided to the destination >>> location/grid if >>> >> the object permissions allow it, with proper transfer of the >>> permissions to >>> >> next owner exactly as if an avatar to avatar transfer or rez in >>> world took >>> >> place on the local grid, without trying to reload the asset from >>> an original >>> >> source. >>> >> >>> >> . >>> >> >>> >> >>> >> _______________________________________________ >>> >> Opensim-dev mailing list >>> >> [email protected] <mailto:[email protected]> >>> >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >>> > >>> > >>> > >>> >>> ------------------------------------------------------------------------ >>> > >>> > _______________________________________________ >>> > Opensim-dev mailing list >>> > [email protected] <mailto:[email protected]> >>> >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >>> _______________________________________________ >>> Opensim-dev mailing list >>> [email protected] <mailto:[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
