Hiya! 👋
I know, I know, you've not updated his GitHub repo in a decade, so I'm not expecting a detailed answer 'soon'...
I'm a very very very slow amateur programmer who just happens to love SL, OpenSimulator, and everything that revolves around that.
I also deeply and profoundly hate C# with a vengeance. In fact, between C#, Java, and Python, I can't say which one I hate most. Although I'd claim that the latest incarnations of ECMAScript are coming very close into the orbit of my hate list...
That said, I like PHP. I liked it mostly when it was a simple language. Now that you're supposed to create phenomenally complex object-disoriented programming, which is a nightmare to maintain and debug, it's starting to appear that PHP is slowly gravitating towards the vortex of C++/Java/C#, which essentially suck every other programming language into accepting their view of the universe...
However, my passion now is Go. This is a systems programming language, hardly used by the vast majority of the SL scripting/programming community. It's as easy to learn as PHP 3 (not PHP 8.4!!) and has the same goal as C (it was developed by a "dream team" of veteran programming language designers, working at Google — Robert Griesemer, Rob Pike, and Ken Thompson), but designed for a contemporary, collaborative environment of programmer teams, released publicly in 2009.
That said, it would have been the ideal language for creating something as complex as, say, OpenSimulator — it's just that it wasn't in widespread use when OpenSimulator started, while C# was trendy at the time. I'm using it for a few SL/OpenSimulator-related tools. One of them is a simple CLI tool to send commands using the remote admin features of OpenSimulator, and, for that, I use your own RemoteAdmin.json file as a good template for automatically generating all possible commands. The concept works rather well, and I largely followed your approach.
Now, all my tools suffer from a lack of support from me, thus they're mostly in a 'broken' state until I manage to get a bit of time to work on them again. Currently, I'm revisiting a set of tools to provide a Web-based interface for OpenSimulator grid users, mostly to allow them to make changes to their own accounts. It reads and writes directly to the OpenSimulator database, which is always a very bad idea, and, worse, it requires the tool to be physically running on the same set of servers that have access to that database. A much more reasonable approach, therefore, would be to isolate my own tools from the actual grid servers, and use the remote admin interface for such purposes.
For that, of course, having your RemoteAdmin.json up to date is crucial, to keep up with any eventual changes on the remote admin API. However, I couldn't figure out how you extracted all that well-structured information from the OpenSimulator cod, turning it into whatever format you use on RemoteAdmin.json.
I therefore have many questions!
- If the
RemoteAdmin.json is automatically generated from the OpenSimulator code, what tool did you use to perform such an extraction? My idea would be to replicate such a 'generator' in Go.
- Or are you downloading
RemoteAdmin.json from somewhere, like we can do for LSL/OSSL keywords, by using the KWDB? If so, where do you get your 'raw data' from?
- What format is
RemoteAdmin.json? It seems rather well-structured according to a very good, clean 'standard'. Is it your own concept? Or is it based on something such as the OpenAPI Specifications, the AsyncAPI Specifications, or even the Postman Collections Specifications? Whatever you're using as your reference, can you give some links to it?
- How do you update
RemoteAdmin.json? Well, I'm aware that you haven't done so for the past decade (and perhaps you won't ever be interested enough to ever do it again), but, for the sake of the argument, if the OpenSimulator maintainers decide to suddenly add a few new commands to the remote admin protocol, how would you capture such information?
- Or do you simply scrap
ApplicationPlugins/RemoteController/RemoteAdminPlugin.cs for the required information, and just do some polishing afterwards, capturing the essence of the code there and just worry about the names, parameters, etc. and so forth?
I really rather prefer not to reinvent the wheel and work within an existing framework, start from what it already provides, and just adapt whatever is needed for my own purposes 😀
I look forward to whatever insights and clarifications you're able to share! 🤗
Thanks in advance!
Hiya! 👋
I know, I know, you've not updated his GitHub repo in a decade, so I'm not expecting a detailed answer 'soon'...
I'm a very very very slow amateur programmer who just happens to love SL, OpenSimulator, and everything that revolves around that.
I also deeply and profoundly hate C# with a vengeance. In fact, between C#, Java, and Python, I can't say which one I hate most. Although I'd claim that the latest incarnations of ECMAScript are coming very close into the orbit of my hate list...
That said, I like PHP. I liked it mostly when it was a simple language. Now that you're supposed to create phenomenally complex object-disoriented programming, which is a nightmare to maintain and debug, it's starting to appear that PHP is slowly gravitating towards the vortex of C++/Java/C#, which essentially suck every other programming language into accepting their view of the universe...
However, my passion now is Go. This is a systems programming language, hardly used by the vast majority of the SL scripting/programming community. It's as easy to learn as PHP 3 (not PHP 8.4!!) and has the same goal as C (it was developed by a "dream team" of veteran programming language designers, working at Google — Robert Griesemer, Rob Pike, and Ken Thompson), but designed for a contemporary, collaborative environment of programmer teams, released publicly in 2009.
That said, it would have been the ideal language for creating something as complex as, say, OpenSimulator — it's just that it wasn't in widespread use when OpenSimulator started, while C# was trendy at the time. I'm using it for a few SL/OpenSimulator-related tools. One of them is a simple CLI tool to send commands using the remote admin features of OpenSimulator, and, for that, I use your own
RemoteAdmin.jsonfile as a good template for automatically generating all possible commands. The concept works rather well, and I largely followed your approach.Now, all my tools suffer from a lack of support from me, thus they're mostly in a 'broken' state until I manage to get a bit of time to work on them again. Currently, I'm revisiting a set of tools to provide a Web-based interface for OpenSimulator grid users, mostly to allow them to make changes to their own accounts. It reads and writes directly to the OpenSimulator database, which is always a very bad idea, and, worse, it requires the tool to be physically running on the same set of servers that have access to that database. A much more reasonable approach, therefore, would be to isolate my own tools from the actual grid servers, and use the remote admin interface for such purposes.
For that, of course, having your
RemoteAdmin.jsonup to date is crucial, to keep up with any eventual changes on the remote admin API. However, I couldn't figure out how you extracted all that well-structured information from the OpenSimulator cod, turning it into whatever format you use onRemoteAdmin.json.I therefore have many questions!
RemoteAdmin.jsonis automatically generated from the OpenSimulator code, what tool did you use to perform such an extraction? My idea would be to replicate such a 'generator' in Go.RemoteAdmin.jsonfrom somewhere, like we can do for LSL/OSSL keywords, by using the KWDB? If so, where do you get your 'raw data' from?RemoteAdmin.json? It seems rather well-structured according to a very good, clean 'standard'. Is it your own concept? Or is it based on something such as the OpenAPI Specifications, the AsyncAPI Specifications, or even the Postman Collections Specifications? Whatever you're using as your reference, can you give some links to it?RemoteAdmin.json? Well, I'm aware that you haven't done so for the past decade (and perhaps you won't ever be interested enough to ever do it again), but, for the sake of the argument, if the OpenSimulator maintainers decide to suddenly add a few new commands to the remote admin protocol, how would you capture such information?ApplicationPlugins/RemoteController/RemoteAdminPlugin.csfor the required information, and just do some polishing afterwards, capturing the essence of the code there and just worry about the names, parameters, etc. and so forth?I really rather prefer not to reinvent the wheel and work within an existing framework, start from what it already provides, and just adapt whatever is needed for my own purposes 😀
I look forward to whatever insights and clarifications you're able to share! 🤗
Thanks in advance!