[Opensim-dev] Global identifiers

[Melanie]

Hi,

Meadhbh Hamrick wrote:
> 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.
> 

We only have a single string field in the backing storage for this data.

>>
>>>
>>> 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.
> 

It was my intention that the service would ignore the cacheable data
portion if the URL was requested, so that the URL containing the old
name as cacheable data would still fetch / connect to the user
record if it has been renamed. This is why I suggested to treat it
as extra path information (like apache does) which is not treated as
part of the URL.
For clarification, if I have /webroot/users mapped to
/webroot/users.php, then a request for /users/<uuid>/extra data will
call the first existing path component, which happens to be
users.php, and pass the path beyond it to the script as a parameter.
I suggested using the same approach, e.g. make /user/ be the service
URL, and treat the uuid and all path compoenents that follow as
parameters, ignoring the name portion and using only the uuid.
I don't know if I make much sense here, but handled like that,
http://www.avination.net:8004/user/bc66ef47-d2f1-41bd-b4a3-a67adca97385/Melanie+Milland
and
http://www.avination.net:8004/user/bc66ef47-d2f1-41bd-b4a3-a67adca97385/Melanie+Ellis
would reference the same user account.

>> 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.
> 

Remote, as in "remote across the hypergrid". The client received
this data from the sim it's connected to, but that sim should not
need to retrieve it from elsewhere. That gets too slow and too
unreliable for practical use.

>> 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.
> 

I should have said "viewerside protocol implementation" rather than
just "protocol". The viewer doesn't handle name changes gracefully,
so it's not reliable, and therefore not advisable, in any case.

>>
>>>
>>> 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?
> 

This is not about trust. A prim is created on a grid and that grid
will forever be authoritative about that prim, and no other grid
will ever be.
So, as far as that goes, you either have to "trust" avination.net,
or display the prim as having no owner, because no other
authoritative source exists.

This discussion is NOT about now to contact a person, or
authenticate a person, or invite a person. This is about how to
DISPLAY the CREATOR name on a prim in the HG without having to do
lots of local sim -> foreign grid name resolution queries,
especially when the foreign grid may be down.

Melanie