On Sun, Aug 29, 2010 at 3:08 PM, Melanie <[email protected]> wrote: > Hi, > > Meadhbh Hamrick wrote: >> a. why use a URL unless you want to have the URL resolve to a HTTP >> endpoint that can be queried in some way? > > We want it to be usable as a URL (to call up additional data, or > send IM, etc) but still carry enough data that simple display of the > textual representation of the name doesn't require a lookup.
that's great, but it doesn't require a URL. maybe a data structure with an optional display name and a URL for the rest of the info. > >> >> b. what if you want to change your name? > > Prims would forever show the name the avatar had at the time they > created the prim, and the grid the prim was created on. This appears > to make sense to me, since that is also the person I presumably > bought it from and I would remember them by that name. If I were to > click "Profile", this would cause a lookup of the URL and retrieve > the current data, including the changed name. I could them attempt > to IM the creator from there. but you're going to REQUIRE servers to now do a redirect from <URL>/<old name> to <URL>/<new name>. or you're going to need to stop treating URLs as opaque data strings. > The main concern here is to remove the need to look up remote data > each time a prim is selected. are you suggesting that the client magically acquired the data without looking it up remotely somewhere. URL construction and caching are orthogonal. > Also, changing avatar names is something the protocol wasn't > designed for. The caching involved makes it a very iffy proposition, > because even the CLIENT caches key->name mappings. This is why > renamed avatars in a local grid appear as their old names the > friends list, while over their heads, they have the new name. > So, whoever renames avatars gets whet they deserve. Chaos. okay. so now you're saying you're going to backfill use-cases to match your protocol. good luck with that. let me know how that works for you. > >> >> and >> >> c. if you want to have >> http://www.avination.net/user/44626b40-13d6-4817-b61b-de5df7b5e7e8/Melanie+Milland >> (or something like it) be that URL, then what happens when i want to >> move from avination.net to example.com? > > You do not "move". The URL defines the avatar known as Melanie > Milland on the avination grid. It will never reference another > avatar. In this case, avination.net is the identity provider for > that account and the account exists in this namespace. > You can't "move". If you want to _switch_ identity providers, you > MAY be able to take inventory, etc, with you, but the identity is > another one. You would no longer be the avatar who created those prims. > It's like email accounts. You call it "moving" from gmail to yahoo, > but you don't move, you create a new account and set up a forwarding. > We may devise a system that handles forwarding, but that depends on > the original grid still being there. As with the email, if you move > from gmail to yahoo and gmail were to go out of business, your mail > addressed to gmail would no longer be forwarded to your yahoo address. so if i decide i don't want to trust avination.net, but i do want to trust example.org, i can't get example.org to redirect to avination.net? > >> >> mixing URLs with URIs isn't the end of the world, but it does make it >> difficult to change names or canonical URLs when you mix them. > > See above. Name changers get what they deserve. Name change is not > even safe on a local grid. Avoidance of lookups in the 99% case is > more important than correctly handling corner cases. > > Melanie > _______________________________________________ > 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
