|
|
|
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 @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: 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. I can see it as possible that this isn't implemented as a kind of anti-griefing measure. With it, it would be trivially easy for Joe Griefer to pick a surname, obtain the list of avs with that surname, then plug the keys into their malicious script-of-the-day.
Without it, that task is a tiny bit harder. Not much, but it doesn't take much to deter the lazier sort of griefer. The question is: is the lack of this function more useful as an anti-griefing tool, than it is a pain in the butt for honest scripters? Myself, I'd put in an intentional delay, or a cap on the number of calls by any one script per unit time, or a 'grey goo fence', or some similar effect. That would be a minor inconvenience for honest scripters, and would greatly reduce its utility as a griefing tool. Just use another search engine, like Google as sort of a proxy.
For instance, for your URL use: http://www.google.com/search?hl=en&q=site:world.secondlife.com+Resident%2BName Then search for http://world.secondlife.com/resident/ Seshat, it wouldn't really be possible to do a surname search as you're suggesting. This proposal is for a direct llName2Key, so you would need to know the avatar's full-name in order to get their key. If you wanted to go by surname you'd have to guess first-names which isn't very easy.
Haravikk:
I spoke a bit carelessly. I didn't mean that llName2Key will give you a list of avs, just that once you have such a list, you can use llName2Key to directly do a bunch of things to avs that you would have to work a little bit harder to do without it. But not much harder. (BTW: Search->People, fill in a surname. Obtain a list of first names.) My main point was that I can think of reasons that omitting llName2Key may have been an anti-griefing decision. But I think it's past time to rethink that decision. Anyone who's a competent scripter can work around its absence enough to grief random people; but the workarounds aren't enough to make a fully reliable gift vendor (since gift vendors are trying to llGiveInventory to specific people). So we have the rather strange situation that it's actually easier to grief than to perform a legitimate task. As an anti griefer measure, it would be completelyl useless.
Either you have a griefer/spammer that targets you specifically - in this case there are tons of ways to obtain your UUID, or you have someone working on the numbers. And they don't care who they hit. They just need a long list of UUIDs, as they are ANYWAY available by a number of means. Let's face it. The lack of a decent Name to UUID lookup just harasses who might make legitimate use of it. Waking this old thread up ... what's up with a llRequestAgentKey now?
We all are using w-hat etc. for long time now, no problems, lot of scripts have a legitimate use for it. Why not eventually implement this into SL, to make us independent from 3rd party databses? When I first thought about the need for llName2Key, I understood that the difficulty would be that a name might be entered that is not unique--like an object or script name, where a number of different objects/scripts in-world might have the same name. However, when we're talking about avatars or groups, duplicates are not possible.
It is also true that UUIDs can be captured through detection and/or sensor events. Any avatar/group UUID that is needed can be found. It isn't like it is secret information to which scripters should never have access. That is why I'm confused as to why this function is not available. Yes, there are third-party databases--but why should we have to rely on those? And why should we have to include the lengthier code required to access those databases, when the information is available? What's wrong with providing scripters with quick access to information that they can retrieve in other ways which is more costly, in terms of system resources? I would also add that this would be good as an llGetAgentUUID or llGetGroupUUID command ... or it could be included as information retrievable via llGetAgentInfo. There are several ways that it could be incorporated--all of which would be easier, for the scripter as well as for system resources, than the hoops through which we currently find ourselves jumping. What a disaster.
In order to determine the UUID of group members I have to scan my sim from multiple places once a minute and once for each name in the group list (that has not previously been documented), just to complete the UUID list. The llName2Key would save tens of thousands of region scans per day for information that should be readily available. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Critical
llRequestAgentKey (llName2Key)
if (llKey2Name(llGetOwner())==llGetCreator())
and not:
llName2Key("Someone Somebody");