Additional Documentation and/or Examples

[iDJHost]

Just thinking of beginner/intermediate user friendliness to have additional bot software options available.

Do you have any additional documentation and/or examples of:
html file pages
php file pages (using curl)
php files of storing and retrieving session id for quicker command processing (database?)
(php is just an example - other languages could/should be ok like perl, node.js, etc)

^^ In regards to README.md "Once RESTBot is running, you can connect to it via HTTP REST commands."
(As opposed to using Command Line curl)

[GwynethLlewelyn]

No, not really. What I've managed to scrap from the Pleiades code is essentially all here; there was nothing else I could find.

At the time of writing this, the only example of integration code I've got is a wrapper in Go, which in turn runs embedded Lua scripts to control the bots. Alas, that project has been done for a customer, albeit an academic one, and, as such, cannot be made public. It does change the original RESTbot, namely, extending its commands — to comply with the AGPL, all the changes I've made are published here, and, to an extent, documented (at least partially so), but not in a very systematic way...

[iDJHost]

I will be working on some files for my webserver. Might have a front-end html page with back-end php files for handling the curl requests. I am undecided if I should make use of an SQL database like mysql or just write the session key to text file.
(.txt file in case people don't know how to use sql databases.)

I may experiment later with making something with node.js as well.

Once I am done, I will make sure anything "personal" is removed and add comments to make it easier for people to integrate it in to their own web-server to run the bot and share it with ya.

[GwynethLlewelyn]

My own experiments used a PDO-type library to store those sessions, currently using SQLite3 :) but easily replaceable by anything else. If I'd only need to store sessions, and not needed to make complex queries, I'd go with a simple KV store instead; in fact, for a while, I used such a KV store as a very fast lookup cache, in front of the SQLite3 backend server — mostly as a 'stop-gap' solution until 'something better' gets developed.
Later I abandoned that extra code, simply because it wasn't worth to maintain it — in my own scenario, with just 20 bots, SQLite3 is more than adequate to handle the load...

[iDJHost]

I typically run MySQL or MariaDB on most of my servers, but since the only thing that ever changes is the "session key" I think a .txt would be more than adequate for most users. just to get things running fast, especially since it will be auto generated by one of the php back-end files. Anyone could modify the files to their liking making it much more advanced for multiple RESTbot installations and a "bot army" if they so choose.

[GwynethLlewelyn]

Well, the session key will change if RESTbot is restarted... the way it works now, you cannot 'force' a session key, i.e. essentially recovering the last session key and 'injecting' it into RESTbot to be reused. But of course you can automate the process with PHP essentially grabbing the key and writing it to a .txt file (or possible a JSON, to save the bot's name as well...).

Personally, I'm not quite sure if I agree with the decision of the original programmers to have these session keys at all. Sure, they provide a slight element of security (you need a valid key to send commands to one of the 'bots, and you'll only get a key if you launched the 'bot yourself, providing your password in the first place), but that should be handled independently of the 'bot's connection to the grid, and would require a much stronger form of security than what is currently being done. That would be a whole new Pandora box of nightmares and headaches 😞

On the other hand, AFAIK, the original developers based their code on the then-existing code for TestClient.exe (which comes with LibreMetaverse as one of the many examples) — basically transforming a command-line interface into a RESTful web service. However, that was all based on ancient code. I did not update the current codebase to make it closer to contemporary TestClient.exe code — way too much trouble! — but I'm aware that a lot of things are done quite differently these days. The way the session keys were handled was present in the code for TestClient.exe, so they just re-used that code verbatim and encapsulated it into a RESTful web service...

So many little things to fix and change, so little time to do it... sigh