Creating an Advanced Greeter

[Malestorm1488303118]

I am creating a store Greeter that saves in a website database the visitors to a store.   The script will communicate with a visitor in a variety of ways based up his most recent visit and purchase history.      Connectiing to the database is fairly straight forward using llHTTPRequest, but I have question regarding performance trade offs.

So as to not connect to the database everytime a person walks in the store, I had planned on keeping a list to keep a UUID of the the last 100 user to enter the store, so I would only connect to the database if the visitor was not already in the list.     But in reviewing LIST documentation in the LSL Wiki, I ran across a statement that lists are not implement in a performance conscious manner and their use should be restricted to very short lists.   This information I read on the LSL Wiki seemed a bit old, and I was wondering if saving and searching a 100 item list of UUIDs is worse than the alternative of accessing the database everytime oneone enters the store?

 

 

 

 

 

 

m 

My questions

[Jenni Darkwatch]

Only a personal opinion: Accessing the external database is probably much more costly than even the worst list algorithm in the history of programming, if the list algorithm is indeed that bad.

[Rolig Loon]

I agree with Jenni.  You probably ought to do the list searches in world.  You don't have to feel limited to 100 UUIDs, though.  Unless you really need to know the person's identity, as opposed to the person's place in your database, you only need to store a portion of the UUID in your LSL script.  Take a look at https://wiki.secondlife.com/wiki/User:Rolig_Loon/High-Capacity_Greeter-Counter , which I put in the LSL wiki library a couple of years ago.  Parts of it are overkill, but the heart of that script is Becky Pippen's algorithm for compressing a UUID by about 84% to save memory.  I have used a version of that counter in a public area for over two years.  It took almost a year before free memory started running short and the script had to start deleting the oldest list elements. 

[Malestorm1488303118]

Wow, yes a very nice script Rolig.   Thank you.    

With the information you have provided, it looks like I can also use the lists to buffer my greeting transactions then, then offload the actual dabase database updates to a slow time of the day when people are not around.

Many thanks

[Amethyst Jetaime]

Be sure to make full disclosure and ask permission of the avatar before adding them to your outside web server.  Also,  who has access to the information?  Its one thing if I buy something, I know that my name is kept in the merchants sales records, but without my permission by just going to their store? A visitor list maker that keeps the info internally as it eventually is erased when it reaches the list limit is OK, but to have my name on a permanent data base outside of SL I would consider a violation of my privacy unless I consented to it with a full privacy disclosure. In addition, if I am spammed by a merchant that I didn't sign up for a group or subscription, then I AR them for unsolicited spam.

Section 8.3 of the TOS:

8.3 You agree that you will not post or transmit Content or code that may be harmful, impede other users' functionality, invade other users' privacy, or surreptitiously or negatively impact any system or network.

"You agree to respect both the integrity of the Service and the privacy of other users. You will not:....

ii) Post or transmit unsolicited or unauthorized advertising, or promotional materials, that are in the nature of "junk mail," "spam," "chain letters," "pyramid schemes," or any other form of solicitation that Linden Lab considers to be of such nature;"

emphasis mine

[Rolig Loon]

That's a very good point, Amethyst.  Aside from saving memory, that's one reason why the greeter I pointed the OP to only stores a compressed UUID.  I don't really need the person's identity.  For counting purposes, all I really need to know is his/her visiting history, so any unique identifier is enough.

[Ela Talaj]

In your application performance is the last thing I would worry about because it is not a real-time system. A real-time system is the one with timing constrains, that is a response to a signal must be received within  a certain time interval. The real-time system in SL would be the one affecting viewer graphics. For instance if you make a moving vehicle like a car or a plane and your software responce latency is too large the movement would appear jerky on the user screen. In another example if you have a door opening on proximity you don't want a visitor to stand there for too long waiting until it opens.

Your application involves no graphics and it does not really matter if a new visitor arrival is processed within 2 sec or 5 sec.