[Opensim-dev] Global identifiers

[Melanie]

I think you may be missing my point, which is that the data is sent
as part of the URL specifically to avoid having to call it when all
you want is to display the name. It's not possible to remote-lookup
all the data all the time. Mono is too badly written to handle that
well and if the originating grid no longer exists, the creator name
would be lost. So the URL must be formed in such a way as to contain
all data that is needed for display only, so it only needs to be
called when communication needs to be established, e.g. IM of FL offer.

Melanie

Meadhbh Hamrick wrote:
> mmm... the argument that tacking an identifier onto the end of a URL
> smacks of premature optimization to me. it should be possible for any
> reasonable client to cache the relationship between a display name and
> a URL. in fact, HTTP has some mechanisms to help you with that. so you
> wouldn't have to query the agent service EVERY time you need the name.
> 
> at linden i developed a pathological dislike of the secondlife:/// URI
> scheme (more on that later), and making the path of URLs "important"
> sort of smacks of that old URI scheme. i understand why you might want
> to stuff names and other information into URLs, but IMHO, the benefits
> you get from one less query is minimal compared to loss of
> flexibility.
> 
> for instance... the reason the VWRAP CALM message exists is because
> jhurliman and i sorta figured out it would be a PITA to support
> multiple revisions of the secondlife:/// URI handling code. john was
> doing some cool stuff with OAuth and OpenID to allow peeps to log into
> a grid via the web. the last part of john's auth process was to
> redirect you to a secondlife:/// URI.
> 
> the idea here was that if the second life viewer was installed, then
> it would register itself as a helper app for that URI scheme and "do
> the right thing" of rezzing you at a certain location on the main
> grid.
> 
> but
> 
> the problem here was that the secondlife:/// URI handling code in the
> viewer would ONLY rez you on linden's main grid. we would have had to
> modify the viewer to handle the addition of a 'loginurl' term. it was
> technically doable, but i was worried about maintaining the URI scheme
> as the defacto way of altering the viewer's startup behavior. i was
> kinda worried that anyone who wanted to experiment with new features
> for the SL viewer would have to perform surgery on the secondlife:///
> URI handling code (and might become durty with respect to the GPL in
> the process.)
> 
> so john and i put our heads together and came up with the CALM idea.
> from a technical perspective it seemed a bit easier to take everything
> that was buried in the secondlife:/// URI and turn it into a LLSD map.
> since we already had LLSD map parsing code, it was pretty
> straightforward to use. it also allowed us to remove the processing of
> startup messages from the GPL'd source, which had been problematic for
> some people.
> 
> so why am i hijacking this thread to tell you about the history of a
> VWRAP component? mostly as a parable about making things as flexible
> as possible. had the secondlife:/// URI scheme (and it's
> implementation in the viewer) not been inflexible, we would never have
> had to take the time to build the CALM scheme.
> 
> starting with designs that enhance flexibility will payoff in the future.
> 
> though seriously, it's not going to be the end of the world if you do
> this "wrong."
> 
> -cheers
> -meadhbh
> --
> meadhbh hamrick * it's pronounced "maeve"
> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh at gmail.com
> 
> 
> 
> On Sun, Aug 29, 2010 at 2:51 PM, Steven Westcot <tsudico at gmail.com> wrote:
>> Hello,
>> I've been reading the mailing list for a while, but haven't really had much
>> input.  I'd like to give my own opinion on the current matter though.  I
>> like Melanie's format:
>> http://www.avination.net/user/44626b40-13d6-4817-b61b-de5df7b5e7e8/Melanie+Milland
>> I think having the avatar name added to the URI would definitely help give
>> attribution and prevent unnecessary polling.  For a hypergrid avatar, IMs
>> and Friends would only need the UUID.  Objects are a different matter
>> though. If the object has left one grid and traveled to another, the only
>> way a human readable name can be discerned would either be to poll the
>> original grid's agent service each time the creator's name was needed or to
>> cache the data in the URI itself.  Having the data exist in the URI would
>> help prevent issues if the original grid was temporarily
>> or permanently unavailable.
>> The only issue I see with including the extra information is if a grid
>> doesn't conform to the standard first + last naming, but has their own
>> identity format.  In cases such as those, the grid's agent/identity service
>> should be able to create a URI that does give proper attribution(perhaps by
>> using existing escaped characters)
>> Steve W.
>>
>>>
>>> Message: 2
>>> Date: Sun, 29 Aug 2010 14:50:08 -0400
>>> From: Mike Dickson <mike.dickson at hp.com>
>>> To: "opensim-dev at lists.berlios.de" <opensim-dev at lists.berlios.de>
>>> Subject: Re: [Opensim-dev] Global identifiers
>>> Message-ID: <1283107808.13484.104.camel at mdickson-linux>
>>> Content-Type: text/plain; charset="UTF-8"
>>>
>>> Sigh
>>>
>>> The name has absolutely zero value for any sort of attribution.  I can
>>> have the same name someplace else (or on the same grid if the grid owner
>>> allows it an uses some other identifier or mechanism for
>>> authentication). Only UUID is valid to identify a specific agent.  Also,
>>> what if I don't want just anyone to know the full names of my users.  Or
>>> if I use a slightly different mechanism to describe a user (email
>>> addresses for instance).
>>>
>>> The core developers have said over and over again that OpenSim is a
>>> framework.  That being the case the semantics of "names" can vary across
>>> grids and how could you ever depend on anything like that to do
>>> "attribution".  Only the Agent service for a grid should be able to
>>> resolve agent id's down to more specific information.  In that way it
>>> can also provide whatever access controls on that information the grid
>>> owner prefers in order to enforce that grid's TOS.
>>>
>>> Mike
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 
>