History | Log In     View a printable version of the current page.  
  • All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you've read, understood, and agreed to those terms.
Issue Details (XML | Word | Printable)

Key: SVC-215
Type: New Feature New Feature
Status: Open Open
Priority: Critical Critical
Assignee: Unassigned
Reporter: Haravikk Mistral
Votes: 97
Watchers: 12
Operations

If you were logged in you would be able to see more operations.
2. Second Life Service - SVC

llRequestAgentKey (llName2Key)

Created: 20/May/07 08:59 AM   Updated: 26/Jul/08 09:44 PM
Component/s: Scripts
Affects Version/s: None
Fix Version/s: None

Issue Links:
Duplicate
 
Relates
 


 Description  « Hide
key llRequestAgentKey(string name);

PARAMS:
name - the name you wish to retrieve a key-for

RETURNS:
A key to be used with the dataserver() event (this is NOT the key for the avatar).
The contents of the dataserver() event will be a string representation of a key, once cast to a key this will either be the key for the agent name provided, or NULL_KEY if the agent was not found.


I really don't see why we don't already have this, especially when it is fairly easy to do, evidenced by the number of good name-to-key databases out there. However, retrieving avatar keys using these sites is slow and potentially fail (as none of them give guaranteed access). Even if the information is distributed in such a way (by key) that this may difficult to do with the current system, a database of names to keys doesn't have that high a demand and could easily be created on LL's end, and added to as new accounts sign-up. It will make it a LOT easier to make more efficient and more user-friendly scripts.

It's one thing to use outside databases for storing your own data, but to have to use them to store LL's data is a bit backwards!

Link to Wiki pages for this feature
https://wiki.secondlife.com/wiki/LlName2Key


 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Smiley Barry - 21/May/07 11:10 AM
Hmm, a nice change would be making it like llKey2Name and llGetOwner that don't trigger the dataserver event. Like

if (llKey2Name(llGetOwner())==llGetCreator())

and not:

llName2Key("Someone Somebody");

Lex Neva - 21/May/07 11:44 AM
Due to the way SL is built, it's almost certain that a function like this would have to be implemented asynchronously as Haravikk suggests. That said, it'd be a whole HECK of a lot better than not having this function at all! LL already has the database that they'd need for this, and the client can query it using the find system. The libsecondlife folks made a program that logs in and does name2key requests using find.

Haravikk Mistral - 22/May/07 02:52 AM
I agree that it would sweet to have it as llKey2Name(), but I think even if they use the same search functionality it would still ultimately be a dataserver() based request, as anything that can't be fetched instantaneously can't really be made into a standard function as the results simply aren't available at the time it's called.

WarKirby Watanabe - 30/May/07 01:34 AM
using the dataserver, or an external database. meh.

I duppose the dataserver might be a bit faster, but it's still not going to be instant.

I think it would be more useful to have a limited function, that would rerturn the key instantly if the target is in the same sim. Like llKey2Name does.

Haravikk Mistral - 13/Jun/07 10:58 AM
Hmm, hadn't thought about same-simulator cases. Certainly for scanners and things it would be more useful, and the search shouldn't be too hard as at most simulators don't seem to allow more than 100 or so avatars in at any one time.

In that event I would go for both, dataserver/llRequestAgentKey() would still be MUCH faster and hopefully more reliable than external sources, plus up-to-date, so I wouldn't discount it entirely =P

Strife Onizuka - 13/Jun/07 02:16 PM
I like the feature suggestion as is. Using the dataserver event is reasonable considering that it might have to fetch the data from the userserver. This functions should probably have some energy requirements.

Angel Fluffy - 22/Jul/07 11:08 PM
Linking to this from the privacy/security meta-issue as this would make life *vastly* easier for third party security systems like SLBanLink.com, not to mention its obvious application for vendors, mailers, etc.

Travis Lambert - 24/Sep/07 08:22 AM
While I'd be perfectly happy with a dataserver event to return this information - I have a feeling that due to the perpetual Mono implementation, new LSL functionality to provide this data isn't on the horizon anytime soon.

If the above is accurate - there's another way to skin this cat without involving any changes to LSL: Make us a Web API to return key information, and have it be queried via HTTPRequest (or an external DB, for that matter).

This would nullify the need for (inaccurate) 3rd Party Databases, and we could query the source instead for reliable key info. I'd think this would be several orders of magnitude easier to implement than changes to the LSL infrastructure.

Haravikk Mistral - 30/Oct/07 07:35 AM
LL did however add llGetObjectDetails() not too long ago, it should be do-able internally. The overhead of using llHTTPRequest() for such calls is a bit high, not to mention fairly complex.

Really all that needs added in LSL is a function hook, since ultimately the processing will be handed over to the simulator to do the actual requesting. The simulator part will not change when Mono comes out (eventually). So as far as SL is concerned it's just another function.

TigroSpottystripes Katsu - 01/Jan/08 11:13 PM
I thought it would be the other way around, the system that compiles and runs the scripts would be improved, but at first lsl would remain the same......

eggy lippmann - 18/May/08 11:27 AM
I was wondering if you've noticed http://secondlife.com/app/search/search_proxy.php
You can do a name2key lookup with it.

http://secondlife.com/app/search/search_proxy.php?q=Eggy%20Lippmann
First link contains my key.

Ezian Ecksol - 19/May/08 04:36 AM
@eggy: That solution has to call even 2 times llHTTPrequest, so code is more complicated and slower than the current web solutions. Additionaly, one can prevent to be found by the SL search, so it could be possible that this solutions doesn't deliver a key.

I would really appreciate LL to give us a built-in function to get the key for an agent name.




Stephen Psaltery - 29/May/08 08:42 PM - edited
Second Edit: Unfortunately it seems SL now prevents HTTP requests from sims from reaching this web service. They explicitly block internal connections. I say this is a travesty more than anything else. At any rate, this can be written as a simple webservice which can be hosted on any web server. If anyone needs help with a script for their webserver that performs this function, IM me in world.

Actually, you only need to do one HTTPrequest call. If you view the source of the resultant page, the key is displayed on the search. When you search for an av name that exists, the "View resident profile" link appears, which contains the residents key EVEN if they are set not to show in search and/or dont have payment info used.

This block of text:
      <div>
         <p class="g">
            <img src="http://world.secondlife.com/images/person.png" /><a href="secondlife:///app/agent/24556873-3005-41a5-a2b4-01a22ffa84c0/about">Resident profile: Eggy Lippmann</a><p>
         </p>
      </div>

Simply check for the substring "Resident profile: " If you find that, then the name you searched for DOES exist. For the key, look at the end of the URL after app/agent/


This yields the key 24556873-3005-41a5-a2b4-01a22ffa84c0, which is indeed eggy's key.

So ONE http request, then you llSubStringIndex(body, "Resident Profile:") if that's not -1, then that resident exists, then you integer key_position = llSubStringIndex(body, "secondlife:///app/agent/") + 24; key target_key = (key)llGetSubString(body,key_position,key_position + 35);

VOILA target_key is now the key of the name you queried.

Is it perfect? No. Does it work RIGHT NOW? Yes. Is it difficult? Not really.

I'm COMPLETELY for this function being implemented as described in this issue, BUT for everyone who wants that functionality RIGHT NOW with only a little more work and annoyance, use my code above. I wrote it pretty hastily. If you want a working example, IM me in-world and I'll whip something up.

Edit: Lack Of Sleep = no semicolons. =P Also, to clarify - this resident profile thing ALWAYS appears first when the name is successfully found to be a resident. That's why we can llSubStringIndex for "secondlife:///app/agent/" without any offsets. It will ALWAYS be the first one you hit provide the "Resident profile:" is found.