|
History
| Log In
|
|
|
|
|
|
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.
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.
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. 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 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.
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.
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. 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. 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......
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. @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. 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. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Critical
llRequestAgentKey (llName2Key)
if (llKey2Name(llGetOwner())==llGetCreator())
and not:
llName2Key("Someone Somebody");