[Opensim-dev] Global identifiers

[Meadhbh Hamrick]

On Sun, Aug 29, 2010 at 3:08 PM, Melanie <melanie at t-data.com> 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
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>