This is a repost compiled from a couple of emails about what needs to be done in terms of coding.
We have three different construction sites: the LSL scripts, the C# bot software based on libopenmetaverse, and the external HTTP server (any server-side language would be ok).
1) The general concept: Script-driven avatars (bots) operate at transceivers for the text. They receive text from human-controlled avatars by IMs (the SL instant messaging system), send this text to one or more external HTTP servers that fuse the text, and receive the fused text to display it on their attachments, which are designed by Elif. The attachments could then be detached and left behind, still carrying the text displayed at the moment of detachment, and new attachments could be formed.
2) The work done so far: The overall appearance of the attachments has been designed by Elif, the general method to display arbitrary text upon them has been coded (following script examples found on the LSL Wiki) .
3) Work to be done:
3a) Extend the bot software called testclient, which is freely available with the libopenmetaverse library, to perform the following tasks: receive IMs and send them out again to the server; attach new attachments; detach old attachments. The bot software is programmed in C# (C-sharp), and we can use Microsoft’s free C# environment for this. Part of the tasks (e.g. detachment) could be done by scripting the attachments inworld using the LSL language.
3b) Program the central server, possibly as external HTTP server using one of the many server script languages (e.g., PHP, or whatever), to receive the text and fuse it to one stream. Of course, we’d need such a server, but that’s not the big problem. Why an external server: the LSL scripting language imposes severe memory limits, which means that the text could not be kept in one central place. If it is enough to display it and forget about it after display, then an inworld solution is possible.
3c) Program the attachment code in LSL so that the attachments receive and display the text from the central server. The attachment code could also do the detaching (lets hope) and determine the lifetime of the dropped attachments (or determine what the attachments should do once they’ve been dropped).
4) Where do we need help: It would definitely be good to have help for each of the points, but definitely for 3b, since this is my weak point and I can’t do it myself.
5) Possible work plan: We first need to solve the aspects central to the concept, i.e., receiving, fusing, and displaying text. Once we have achieved this, we can work on playing around with dropping and renewing the attachments. That means: we urgently need the server-side programming done! For that we need (to talk to) someone capable of doing the necessary scripting on a HTTP server.
Remarks: The idea would be that the external HTTP server receives text from different sources inside second life, processes (i.e., fuses) this text, and make the fused text available to display it in Second Life. Objects inside second life can also work as HTTP servers; supported methods are GET/POST/PUT/DELETE. Using this would probably be useful to send the text out. Objects in second life can display web pages. All that is required for us is plain text, as far as i see. Probably some simple prototype HTTP server wouldn’t be a major coding effort for someone who knows how to do it.