vwrsearch.secondlife.com is down

[Sasun Steinbeck]

Yes, she does exist: https://my.secondlife.com/tula/#about_tab. Her legacy name is "Tula Resident". Your response proves my point exactly. If you don't know exactly how to parse the search results, you'll get bad data, as in "this person doesn't exist". Secondary Resident, however, does not exist. But you won't know that until you parse over 160 search results scattered over 20+ pages that you have to load. See what I'm saying? It's a mess!

Do you have any authoritative information on exactly how search results are sorted? Can you share that information please?

Don't assume that SL products can just assume that every name given to them to check is valid, current, and an existing avatar. I regularly get huge lists in the tens of thousands of avatar legacy names to import into my system, and almost always there is a good 5-10% accounts that no longer exist, are incorrectly capitalized, or just plain spelled wrong via manual copy and paste errors. If one of those lists includes the former Secondary Resident, I have no choice but to parse through that entire mess to figure out that that avatar doesn't actually exist. With any luck I'll get the actual avatar not on page 200 but on page 2, but I can't really count on that, can I? I have to keep parsing until 1) I find the verified name or 2) get to the end of the search results. So I must always be prepared to parse an unknown number of pages.

 

 

[Miranda Umino]

You assume than vwsrsearch was perfect .. it didn t ...you had already some wrong results 

 

Prove : your own post was criticizing vwrsearch :

https://lists.secondlife.com/pipermail/secondlifescripters/2011-October/006390.html

[Sasun Steinbeck]

Where did I say vwrserach is perfect? And what does vwrsearch throttling have to do with the current discussion? Nobody in their right mind would assume that any LL service is perfect, lol.

The fact that the old search isn't, and never was perfect, and that the new one isn't either, just proves my point that we DO NEED a reliable name2key service that doesn't make SL developers jump through hoops to parse the search results and returns useful error information.

[Miranda Umino]

Some people from 2006 have told already this.

Probably it s better to change our logic of scripts than to wait the birth of an hypothetical perfect webservice

[Sasun Steinbeck]

It's not "better", it's either do or die. As if we have a choice at this point, right? THAT'S what sucks, that we all had to scramble to fix this. I had to convert or some key products would have continued to be non-functional like they were when vwrsearch first went down.

And I'm sure you wouldn't argue against pusing for a simpler, more reliable web service, right?

[Miranda Umino]

Personnaly , i am uing at the most the keys. because even if they are longer than names they can be better compressed, and because nearly every functions requires a key in parameter.

 

And it s faster to index in a database, too

I m storing the couples in my side the couple names,keys. Because it allows me when i want to fetch some keys , to call my private url with several names in parameters and fetch in one http call , several keys .

I don t care to store every keys . Only the keys from my most important groups are enough . The testclient program from libomv and the command groupmember  gives me the keys . And it can fetch some thousands of keys quickly

 

Even if Linden would create a "perfect webservice" , there are great chances it will allow only one name in parameter, and not a list

 

 

 

[Norton Burns]

You really seem to be missing the point here.
If your required avi is nearby when you grab their details, then it's your choice whether you store name &/or key, as both are readily available to you with zero uncertainty.
If you need, for instance, a user to fill in an admin list in a NC, then you have no alternative but to rely on some form of search. 

I shall simply avoid the issue as much as I can in future - I shall only check names against keys at the point of interaction, when I can also be certain of my data being accurate. For some scripters, this isn't a viable alternative.

[Dahlia Orfan]

Could you give a link towards this jira ? I cannot find them.

[Norton Burns]

They're all BUG Jiras, not visible to most users

[ab Vanmoer]

Dahlia,

Unfortunately LL in their wisdom (or rather complete lack thereof), decided that their paying customers are not mature enough to understand why LL simply can't be bothered to fix bugs or to even keep their paying customers updated as to the status of these bugs.

So, at some point LL changed the JIra system; now only the person who opens a Jira is able to see it., that way they don't have to bother fixing bugs because they can pretend that each bug only affects one person. Older Jiras however are still visible though.

It may be helpful if every one affected  by this bug opens a new Jira, it might just kick  LL into some action, to save effort when creating a new Jira,  just copy and paste from the old - WEB-2362

It is really unusual to find a company that has managed to stay in business while treating its customer with the kind of contempt that LL reserves for its customers. This is a huge bug that affects thousands of people and LL can't even be bothered to let us know if they have any intention of ever fixing it. The last time it broke three years ago, LL took it seriously enough to have it fixed in one day. Current staff JUST DON'T CARE!

 

 

[Dahlia Orfan]

The numbers of these Jira please ? You said *four* jiras. I cannot find it. And of course it is not visible unless you are logged.

[Dahlia Orfan]

"only the person who opens a Jira is able to see i" I did not know that ; Im gonna open a new jira then.

[Miranda Umino]

No i ve missed nothing .

 

But you , you are totally wong :

 

Firstly , you assume than you can t store keys in notecards  . I don t see why .

Notecards can store keys without problem

 

Secondly , you assume than the instance from Susan happens significantly .

 

But in reality , it happens very rarely .

Your searched name has  more than 99.9% chance to be in the first page .

It s logic : even if the name is not th first name returned in the top of the list , they are few chances , they are not displayed in the rest of the list .

 

And to meet the case of "Tila resident" from susan , the conditions should met :

- there are more than 20 names returned ( low probability  who decreases exponentially with the length of the 1st name +1 for the Resident family or with the length of the 1st name + 2nd name for the names with familes other than Resident  )

- the name really searched is after the 20th and not before. For Instance with a list of 21 names , the name searched has 1/21 to be in the second page so 5% .

 

To test it , i have picked up 1700 uuids/names randomly from a groupe .

I have created an application to call search.secondlife.com . 

When the result doesn t give "sorry , no result found" , i parse the page . Parsing is easily and quickly done with a Regexp . If i have not found the name i am searching in the 1st page of results  , i send an error message . 

I have checked with these 1700 names . What i get ?  ZERO cases like the "tila resident" from susan

 

I have told myself that the samples from a group can be different from samples from in_world . Indeed , some memebers of group can be very old .

So , i went in several region , collecting keys vi llGetAgentList , their names via llKey2name , and doing a search with their names to verify if the key returned in the search is the correct key .

 

I have checked around 500 names . What i get ? ZERO cases like the "tila resident" from susan .

So yes , the case of Tila resident exists , but is not signficant . the observed probability ( or the frequency as you wish ) is inferior to 1 /2200

How much are there people in the same case as "tila resident" , ( can t be fetched in the fist page of search.second.life.com, but could be fectched in the other pages )  compared to the 35 millions database users, or evn compared to the 1 millions users connected per month   ? Very few .

 

 It s neglectible compared to other possible errors you can get , or you can create yourself in your process

 

 So yes , your argues have nothing convincing

 

[Sasun Steinbeck]

I have 1.2 million names/keys in my database. Let's say for the sake of argument you are correct, that 99.9% of them will be easily found on the first page. You are probably right.

So let's see, 1,200,00 * .001 is... 1,200. Yes, 1200 names, if that percentage guess is realistic, will not be found. Is that number acceptable to me? Maybe for you, but not for people that work with databases at this scale. My point here is not your specific numbers, but that "almost always" or "99.9%" is probably just fine for someone searching a few thousand or a few hundred thousand names. But when you get into the millions, "almost" is just not good enough.

I really do not have a good idea of what percentage won't be found on the first page. But I will tell you that I was very surprised at how easy it was to find a few. I didn't write a program to search my database, I just looked at RANDOM at a list of names and started doing a few manual searches. I tried searching for a few dozen, then found Tila, and also found Secondary a short time later. By manually searching. So I'd be very curious what the real numbers are on how many residents won't show up on the first page.

I'm glad to hear that you tested so many names and had no problems finding them on the first page. That's good news. After finding those two names I was pretty darn worried. Maybe I just got extremely, incredibly lucky finding those two examples of why assuming that your search result will be on the first page is a bad idea. Maybe. I may take some time to run some tests like you did to really find out. But if it takes me the same amount of time to just fix my search code to loop through all the search page results, I'd rather just make that work - then my search results will be better in the end.

I must reiterate that all of this pain would be completely irrelevant if we had a decent and authoritative API to call to do this, instead of the complicated, messy kludge that we have now.

[Miranda Umino]

When you deal with 1 million keys , 1000 accounts are acceptable . You don t work in military sectors or energetic sectors or health sector or other critical sectors . You work in second life .

You tell yourself

I regularly get huge lists in the tens of thousands of avatar legacy names to import into my system, 

and almost always there is a good 5-10% accounts that no longer exist, are incorrectly capitalized,

 or just plain spelled wrong via manual copy and paste errors

5-10 % is 50 times more than 1 per 1000 . So , your main problems is to find a solution for these 5-10% . Not for the 1 per 1000 .  

 

I am not surprised you could found them easily if you do a manual search :

it s because you have run a search with few letters .  If i search "AA" in people , i would have several thousand of pages . But your process to verify UUID will in practice use the length of the name . And people with only two letters and who can t be found with their family name ( for instance they are "aa resident" "ba resident" "ca resident" )  are very rare in the SL population 

There are more names with few letters when the users are not "Resident" family , but the name of their family allow to be more efficient in the search . (   For instance http://search.secondlife.com/client_search.php?q=aa.keng&s=People gives a list with only one element

To add , it s not because when you get a long list with a searched name , an another search with a name from this list will give many results . 

For instance , tula88 resident was in the result of tula  resident . Tula27 resident too . Tula30 resident too . 

Tula( display name)  petulalake resident too

But if you search tula88 resident , you won t find tula resident , and the majority of names you got with tula resident :

http://search.secondlife.com/client_search.php?q=tula88&s=people will give only 1 name..

http://search.secondlife.com/client_search.php?q=tula27&s=people  will give only 1 name..

 http://search.secondlife.com/client_search.php?q=tula30&s=people will give only 1 name

http://search.secondlife.com/client_search.php?q=petulalake&s=people&mat=7 will give only 1 name

And finally , when you have searched , you didn t fill a second name . Your script will fill it and so the results of the serach will be smaller 

 

In fact , you have searched randomly the  characters of a name before to find tula . But you have not searched randomly the length of the name ( you didn t pay attention your inputs were always small ) . So it was not a correct random 

So it s only specific to particular people and it explains why it s easier to find someone manually who won t be in the forst page than to check some random names with a "real" name stored in your script , or database

[Noddington Schmooz]

In my shop, I have vendors with gifting capabilities. Visitors to the shop can click on the "Gift" button, input the name of the intended recipient into a text box, and send them a gift copy of the item in the vendor.

My script used llHTTPRequest to parse results from vrsearch.secondlife.com through a Google app (name2key) to return the key of the avatar in question. If the requested name didn't exist, it got flagged as such; if it did exist, it would return the correct key, every time.

With vrsearch.secondlife.com down, I cannot do this. I've rescripted to use http://search.secondlife.com/client_search.php as the search engine, but it's kludgey at best because it is dependent upon the customer inputting the name correctly. If they put in a Display Name, they can get any number of odd results. I've worked around this by scripting in an extra "Please confirm that you wish to send this gift to [NAME]" dialog, but that is a less than ideal situation.

Since you seem to be saying --repeatedly-- that vrsearch.secondlife.com being down is a non-issue, I was wondering if you had some sort of script you'd be willing to share with the rest of us that will allow me to have a user input a name, and have it checked against SL's search database for (a) existence/non-existence and (b) return an absolutely correct UUID.

Thanks in advance.

[Innula Zenovka]

MartinRJ Fayray posted a workround in the Forum Scripting Library  which I find very helpful indeed: http://community.secondlife.com/t5/LSL-Library/Name2Key-vwrsearch-workaround/m-p/1964797#M672

Thanks Martin!

[ab Vanmoer]

 

Today Brooke Linden updated BUG-2104 (Changes to vwrsearch url breaks name to key functionality) as follows:

We recently deprecated support for vwrsearch, a web page service that allowed getting the resident key from a web page. We recommend updating any products which used this service with a service that can provide this information. There are several options, some of which are listed here:

• Hosted services, such as w-hat (
  http://w-hat.com/name2key)
• HUDs available on the Marketplace (
  https://marketplace.secondlife.com/products/search?utf8=%E2%9C%93&search%5Bcategory_id%5D=&search%5Bkeywords%5D=name2key)

We apologize for any inconvenience this has caused you.

 

I responded:

The alternatives you offer to vwrsearch are completely unacceptable, and indicate a

complete misunderstanding

of the requirements as well as the magnitude of the problem.

Firstly, how exactly do you propose that I integrate the marketplace HUDS you link to into my vendors? Even if it was possible are you suggesting I buy a few thousand HUDS to distribute to my customers?

Secondly, I know for a fact that many if not all

the HUDS you link to actually use vwrsearch for their name2key lookup

.

Thirdly w-hat is a 3rd party service that offers no obligations, is often out of date, and may be withdrawn at any time on the whim of the owner. It is not an acceptable alternative where long term reliability is a concern, although ironically it now appears that it is probably far more reliable than Linden Labs.

Although MartinRJ's workaround has been a welcome temporary workaround, it is unfortunately not a long term solution, firstly due to the already mentioned inability to find users hidden from search, and also because historically the search web page format is more likely to change than the vwrsearch pages that have remained static for years.

I can not believe that it has taken nearly TWO months

of uncertainty and the best that you can come up with are a few completely unworkable suggestions!

. These suggestions did come as a bit of shock, not only because of their impracticality, but also because I thought that

vwrsearch had been fixed as it has been working reliably once again for at least the past week!

 

Yet another indicatior that LL doesn't have a clue as to what they are doing!!

ab