Hierarchical naming systems for llEmail() use

I'm very curious to see an example of this naming system you mention, Eggy. I'm working on a project that uses email for communication and would love a way around hardcoding recipient keys in scripts or notecards.

In my autoupdater and my remote vendor both I have the child send the relevent key information and many other thing in a comma seperated list as part of the secured email. The server parses this information and stores the keys to variable. Those variables are then used for update emails, sending the object purchased, etc. There is no hardcoding whatsoever in any of this type of information. The only things hardcoded are XOR keys, md5 phrases, the passwords I use instead of commas to seperate each variable in the stringed list, etc.

However if he has some way to prevent having to have the SERVER key coded into the children (other than using inworld/outworld communication) I would love to know about it. I really wish there was some way to find a servers key in world on the fly in case of detrimental server derez.

Also the server has 15 different email scripts and could have even more if needed. Since the 20 second delay on emails is on a per script basis I have the main server linktell email script1 first. Then the next email it sends out goes to script 2, etc. The email scripts are just passive slaves waiting for a linktell with a string of information to email out. This way I can send 15 emails every 20 seconds from the server and thusly handle a large number of children and possible simultaneous requests. So if 4 people buy somethign at once (I wish) then they would all get it nice and quick. No waiting for a full minute for the 4th person just because of email delay.

Well we were planning on open-sourcing it, but most of it will be obsolete when the new version 1.7 introduces global shared memory, and we haven't gotten it to the point where it's pretty enough to package up and release.
As soon as I can get in touch with Christopher Omega we'll get back to you.
You should probably realize that, if your application is anything like ours, with the amount of messaging you'll be doing, it would be miles more efficient having an external site doing all the storage and coordination.
It's only $5 a month, so even if you're not making any money you can pay for it off your stipend.
In the mean time, if you wish, I can give you some pointers on how we're going about it.

I don't think I'll need any code; pointers and tips should do for now, especially if 1.7 comes out sooner rather than later. My project isn't anything huge. It's just a bunch of client objects requesting things from a server object, with the occasional ping-like message every couple of hours or so. I wanted to keep it entirely in-world so that anyone could set it up and make it work without needing external resources. My only real concern was the hardcoding of server keys in the client objects.

Well no matter what network topology you choose, you have to have a way of finding a first node to connect to, so that it can tell you about other nodes.
So you can either hardcode it, add a dialog to let you change it later, or, if distance is not an issue for you, use a sensor or a listener - make clients shout and use the listener on the server so you wont ever need more than one listener.
The point of a naming system is that you'll only ever need one key to reach all your objects, and the rest is reachable through a user-friendly name of your choosing.
Once you can message objects by name, it's trivial to code a parser around it so that you have a whole meta-language like call("MyScript.MyRemoteProcedure(1,2,3)"; or heck, even add MySim.MyObject.MyPrim.MyScript.MyRemoteProcedure(1,2,3)
Personally I would recommend you do what I did and shelf these fancy workarounds - LL is going to give us a "shared memory" system in 1.7 that will render all this work obsolete.
If that's not good enough, it's trivial to just use a MySQL database for all your Name2Key-resolving needs.