This is sort of a follow-on from the 'Scripting Client" topic (Scripting Client), but I think the angle is sufficiently different that I should start anew.
As I remarked in that other thread, I’m not particularly a fan of the BeOS/Haiku supplied scripting protocol. I won’t repeat my reasons here except to say that it seems overcomplicated and underspecified. Then Adrien pointed out Willy Langeveld’s ‘BeBREXX’, with its own scripting scheme. I got intrigued, and started playing with it (for rather longer than I anticipated ). I now think it’s better suited to many more uses of scripting than the BeOS scheme.
The main thing is that it’s much easier to incorporate in a Scripting Language, – like REXX, but also all the others like Python or Ruby --because it’s text-based. With the other scheme, ‘hey’ is the only (somewhat!) convenient interface that’s ever appeared. And it turns out it can’t handle some perfectly legal constructs that some apps (like Tracker) already provide.
In this scheme, a scripting message is simply ‘command + arguments’ as a text string, and the target app returns any appropriate result also as text. This is easy to handle in any of the common scripting languages. A minimal API to the existing shared library would be all that’s needed.
The other major difference in philosophy is that the message is sent to a global port with a specific name, not the application itself. This means that there could be well-known ‘services’ with their own names that could actually be provided by any of several apps, at the user’s choice.
It is also a much “flatter” protocol than having stacked “specifiers”, but unless you want to control the 5th View of the 3rd Window or something, a flat command is usually what you’ll want.
There is no built-in “Discovery”, as the BeOS scheme has, but that’s one of the ‘underspecified’ areas, to my mind. There seems to be no way of specifying what parameters a B_EXECUTE_PROPERTY call might require, for instance. Adding some discovery to this scheme should not be hard, anyway. Just define a protocol for how, say, a “getcmds” message should be responded to.
Behind the scenes, there is a small shared library that any app or client that wants to use the scheme will link to, and another small server for managing the ports that is launched automatically when first needed.
Anyway, BeBREXX includes a demo, but I thought it would be useful to have a commmand-line client, equivalent to ‘hey’, for the scheme, so I wrote one. In respect of that tradition , I’ve naturally called it “yo”. I’ve put a self-contained demo together (using Willy’s “Squares” demo app) that you can play with. It’s at http://goodeveca.net/haiku/yo_scripting.zip
or on BeShare (if I’m online) under the same name.