Question about email in SL

I've recently made a very simple "object server" script that sends out objects to avatars via emails from a "client" object(like a vendor). I've read that receiving emails has a limit of 100, and then the rest get bounced. So my question is: Does the 100 limit mean up to 100 for a given period of time, or 100 and that's it forever?

it caches up to 100 when the av is logged out, then they get bounced. When they log back in it resets to 0

whoaaaa, what do you get 100 of? Not IM to emails...

sorry guess I wasn't clear lol..

you cahce 100 IMs within SL. If you have them forwarding to email, you'll be able to get more than one hundred in email, but your av in-world will still only show 100 IMs when you log in

I'm not sure, i understand your problem correctly, but i will try to post an anwser to your question.

I _assume_ that your script works like this:
- User touches the client object (i.e. Vendor or sth similar)
- Client object sends a email to your server object
- Server object receives the e-mail and process it
- Server object sends the item to the user

If this is, how your script works, then the anwser to your question is:
Every object can store/cache up to 100 mails into its mailbox (mails sent at <object_uuid>@lsl.secondlife.com).

Once the box is full, all other mails are bounced. When you use the llGetNextEmail() function, the first mail matching the filterrules it received and the email() event is triggered. This email then is removed from that queue.

So if you have 10 mails in the queue, you can get 90 more before the box is full (10+90=100 ^^). If you use llGetNextEmail() the email() event is triggered and the mail is removed from the queue. Now you have 9 mails in the queue and 91 can be received until the queue is full.

The email event also shows you how much mails are left (thus you can deceide/find out how full the cache is).

For more information, check this two links
http://www.lslwiki.net/lslwiki/wakka.php?wakka=llGetNextEmail

http://www.lslwiki.net/lslwiki/wakka.php?wakka=email


You need to set a decent timer, on which your script will check if there are new (or any) mails in the queue waiting to be processed. If you set the timer to high, you'll risk that the box gets full. When you set it to low, it maybe negative affects the performance (cause lag).

I'd say, a value of 10-30 second seems pretty fair (unless you expect some pretty high traffic/mail requests, then maybe 5-10 sec would be decently fair).

You could also try to implement a dynamic change of the timer frequency. Maybe first set it to something like 60 seconds. And if you notice, that there are much emails comming in (more then 50), lower the timer by 10-20 seconds. If you notice there wasn't any mails one (or more) timer cycles, then increase the timer by 10 sec (to a maximum of 60 or 90 sec). In this case, it would be important to set a max time limit, so that the script won't take too long cycle and miss a suddenly increased mail traffic (hence losing mails due to bounce).

Lafiel, thanks for the answer. And yes, that is exactly how my script works. I just needed a clarification on the limit.

Just a little addition: You should note, that the object email (<object_uuid>@lsl.secondlife.com) is not a permenent one.
If you pick up your server object and rez it again, the mail address will change and your vendors (client objects) will stop working.

So you should at least have some kind of external communciation (with a webserver) (or maybe try with one of the free storage scripts/system already available).

This would be the preffered way to handle this:

Server:
- When server rezzes, it sends a llHTTPRequest to the webserver (page you use to storage the variables) and submits it's current UUID
- Webserver/Storage script, receives that request and saves that ID (or variable in case of a storage system)

Client (Vendor):
- When client gets rezzed, it sends a llHTTPRequest to the webserver (or storage system) and reading the uuid from the server object
- Webserver (or storage) submits the current uuid to the client
- Client uses this information to generate the e-mail
- Client should also regulary send new requests (maybe on 5 min intervals) to the webpage and checking if the server object uuid was changed and update the mail address if necessary


At the moment, there is no other way to make sure that the mails will still be sent to the server object, after it was rezzed. Well there maybe are some other ways, but i don't know of any.

Thanks for the addition. I did notice the key changing when taking and putting a server back in-world while developing the script, so I had put in code(and instructions) that when the owner touches the server, the server tells the owner via llOwnerSay the server's key and email address and he/she should set the clients/vendors accordingly. But when I get there, I will certainly look into the info storage script idea.