Kehf Nelson

I agree about the complexity. Simple SendOK permission bit in the script. BodyLength should be ok, have a library I use for http that takes care of that. I appreciate the feed back, will be posting the working tests as I fiddle with the project.

Yup I looked at those systems but near as I can tell they are not opensource. Part of the fun for me is learning how to build and do it.

Been fiddling with this idea for a while, I understand the basics but curious as to the best practices for this type of system. At this point I'm not asking to help with the actual scripting, that will come later. For now I'm picking the forums collective brains as to the best way to handle the flow of events. -- Looking to create an open source SL Wide method of "Chatting" via huds. Think, Rescue-Beacon, GPS locator (Press a button, Avatar as it these Grid Coordinates) , Very Limited (64 Character) llTextBox() means of communication. Minimize Resources, Avoid Spam through a system of authorized senders, perhaps multiple "channels", and have some means of scalability. I have access to an external KVP system so depending on the SL structure, can have all the messages reside there, or keep a key of an in-game server up to date after rolling restarts. How much of the finished system is in game or external depends on issues of scalability, lag, http request limits, etc The Flow of this sort of thing is where things get a bit sticky for me. Let's assume the following scenario of a Rescue-beacon. You have many possible victims "V" and a smaller population of Rescuers "R" Either V or Rs will get a little radio hud thing. V huds have 1 button, "Help me ON" or "Help me Off" R huds have a button that opens up a llTextBox() dialog and lets them respond to the V radio that's sending the helpme When a V presses Help me, the R's are alerted to that, presented with the ability to send a short message via an llTextbox back to the Help Requesting V's hud device. Assumptions: -V can only send one helpme Ping every 5 minutes -R can only send one llTextBox every 1 minute -S will get a rolling restart and its UUID will change at least once a week -We don't know how many R's and V's there are at any one time -HelpMe Messages contain the sender's Key, Location, TimeStamp, and Receiving URL for messages back Idea 1: Using KVP primarily R huds user a timer, every 10 seconds they query the KVP server for the "latest/last" message, if no change do nothing V requests a helpMe, their hud, WRITES an alert request to KVP (Receiving HTTP URL, to communicate back, location, timestamp, etc) R 's hud beeps when the checked message != to the previous message R chooses to send a message back via the inbound HTTP URL that corresponds to that V prompt Problems: Not very feature rich, multiple messages, or events could overwrite each other, no server side processing/cleanup Idea 2: Uses an in game "server" S starts up, writes to external KVP it's in game UUID/URL. R and V get the UUID/LSL Query URL of the server "S" via the external KVP server, each time they change regions or something R on a timer queries S for the last "batch" of messages V requests a helpme by sending a message to S with (location, timestamp, etc) V starts a timer to query S for updates to it's helpme S Packages that request into a message R receives that message on it's next query R responds to that query via an llTextBox back to S V receives that response from S Would get a single point of authority for all the users. Probably run into a limit of HTTP requests, I assume this wouldn't scale very well, too many inbound HTTP posts to S? More ability to manage a list of messages, cleanup. Idea 3: Bit of a hybrid, might scale better if there are... 50 or so Rs S starts up and writes it's UUID/URL S on a timer queries KVP and grabs the last X number of messages, sorts, prunes, organizes via LSL (Cleans up the old messages and is the authority for message order) S Writes to KVP the CurrentMessageDocument R and V query KVP on startup or region change for S's UUID/URL V goes to Idle R on a timer Queries KVP for CurrentMessageDocument Time passes V Writes a HelpMe to KVP (Location, Time, Receiving HTTP URL to communicate back) S catches that HelpMe Record on the timer S Amends to KVP the CurrentMessageDocument, deletes the HelpMe KVP Record R on a timer sees a change to CurrentMessageDocument R responds via an llTextbox to V on the Receiving HTTP URL submitted in the helpme message Idea 4: Rolling message pruning S starts up, queries KVP for all messages on a Regex'd key S Prunes old records maybe leaving only those messages that are < 30 Minutes old S starts a timer to Prune every 60 seconds. V Starts up, goes idle R starts up a timer and Queries KVP for the latest messages R Sorts messages llOwnerSay'ing "new ones" V sends a helpMe R on a timer Sees a new message R can Respond back to the helpme Record on V's URL Uses the S for External DB management only. Scalable? So, what are your ideas on how to "skin this cat" Is there a better way to flow the information that would make communication scalable for all involved?

I had this need and ended up learning some simple node.js to create an external KVP database using the free tiers of Amazon AWS and mongoDB. It works, supporting about 300 users with it. This required creating a little library for my LSL scripts to access it. My initial testing shows the system at that tier being able to comfortably support about 40-60ish requests per second. I made it all open source. https://github.com/knscripting/Simple-KVP-Node-for-Secondlife Example of how I use it. The objects can request a "Current-Version" record from the external KVP pair, If the current object is below that version, give them a link to download a new one. Or, that version number can be used to trigger a LinkSetData update for the object if there's a considerable amount of required configs.

I've noticed this as well, I get around it by hosting my own external KVP system for backups and settings' conflict resolution. On the device I maintain "Active data" A periodic LSD backup of the important user config which gets mirrored externally. I use unix time stamps to maintain a hierarchy of restore points. Other data gets broken down by use. Config/Player Content data is force written externally each time it is changed, and that external backup always wins in a restore. If the external source is not available then the local Config Data hash is restored from LSD. etc .etc. Things like XP or score are restored from highest value of all restore points. System states are never backed up. Can't think of a better way to do it, but if anyone has ideas, I'm eager to learn.

1. I know the correct answer to my "When?" question here is something like: "I'll be ready when it's ready..." But what's the "best guess" to when LSD will work grid wide? Mid 2023? 2. How much faster or slower are we thinking LSD will be compared to Desc strings on "settings" linked prims? 3. How bad of an idea would it be to use LSD for link_set object communication vs link_message for larger strings/data? 4. Feature Creep, don't suppose we could get a llDumpLinkSetDataToJSON() and llParseJSONtoLinkSetData() too? ---> Shameless Plug https://github.com/knscripting/Simple-KVP-Node-for-Secondlife

I've been needing external data storage for a while and decided to try to do something about it. Firstly, this is my first node.js attempt and it shows. Any ideas are welcome. So far. it works: https://github.com/knscripting/Simple-KVP-Node-for-Secondlife There are a few LSL examples in the repository. I have some important things on to do list. all comments welcome.