Thinking about Scripting

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 :grinning:). 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 :grinning:, 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
or on BeShare (if I’m online) under the same name.

1 Like

What is the different between something like rexx to the scripting language yab? I would like to undersrand why this is better to make scripts.

As Pete mentionned what matters here is not really the language. It just happens that on Amiga, REXX was used to implement talking to other applications, a bit like hey on Haiku. The language itself is not all that great, and it seems modern Amiga like systems will rather connect the feature (let’s call it “ports”) to other languages like lua.

Anyway, this is a replacement for hey and the related application interface, which is maybe more esasily integrated in non-c++ scripting languages.

Which makes me think the native scripting would be better exposed in a powershell like system… mh… maybe a future gsoc idea :wink:

1 Like

Ah, ok thanks

What he said… :grinning: Thanks, Pulkomandy – you got in there before I did.

A quick update, though. I of course found a bug in my version of the ‘Squares’ demo (typo+uninitialized memory, so naturally it never showed in my original testing :unamused: ! Fixed now (I think!) but the couple of folks who’ve already downloaded it should be aware.

EDIT: And of course then I left my debug printouts in!! All – umm – squared away now I hope.

I also forgot to mention that in the process I added a ‘getcmds’ experimental ‘discovery’ command, with a possible stab at a reply protocol. It’s not documented. I’ll add a note in the README later. (It’s way bedtime here in California…)

1 Like

For the exceptionally lazy among us, not motivated to get the stuff and poke through it to see what you’ve done, could you clarify - are you still talking about an alternative protocol, with different structure at a different port etc. - which I guess means, for new applications only? Or a different interface to existing applications’ BeOS scripting features?

I’ll second the comment, that REXX is not the greatest language - but also take issue with it, in one respect. The parsing feature is something I guess no other language will ever equal, as a simple, painless way to extract information from a text protocol.

Yes, it’s an alternative protocol. To emphasize, it uses global named ports to receive script messages, rather than the app itself. An app simply registers a port with the desired name with the PortManager, supplying a messenger to itself. Like:

   pman = new PortManager();
   status_t res = pman->Register("PlayAudio", BMessenger(this));

and then process arriving messages in its MessageReceived method. There are utility PortManager methods to ease parsing the message and so on.

So, yes, it would have to be written into an app, but of course so does the ‘hey’ protocol if you want to control anything but windows and such.

The PortManager does in fact use a custom specifier internally, to handle port registration. The whole thing is pretty lightweight: the shared library is 21kB, and the PortManager is 28kB.

You are completely right. However, I suggest to don’t reinvent the wheel and look at OpenBinder.

1 Like

Well, we have BeBREXX which is already working on Haiku and with one app using it, and a long culture of usage on Amiga we can get inspiration from. And on the other side, we have OpenBinder, which as far as I know was never ported back to Haiku, and is somewhat used, but in a much reworked version, in Android. I’m not sure one is more “reinvent the wheel” than the other.

After chatting about scripting with Pete on BeShare, I had a look at the way PhotoShop does it; found a nice article at Besides native scripting for the particular OS (Visual Basic or AppleScript), they have Javascript.

I think Javascript would make a good system scripting language because of its popularity (lots of libraries available, and fast interpreters), and I can see how old BeOS application scripting could fit into the Javascript object model, where you might have code saying something like app.window[0].title = "New Title", a lot like the BMessage specifier stack, which Hey uses like: hey application set Title of Window [0] to "New Title".

I don’t think you have any idea at all of how the OpenBinder was designed.

I’d completely forgotten about OpenBinder… However, it’s a bit of apples and oranges. As Adrien points out OpenBinder never seems to have been used in Haiku, although Dianne claims it ran in BeOS. It’s a much more ambitious paradigm than a more straightforward scripting IPC.

I’m actually wondering, in line with the sparse response to this topic, if ‘scripting’ isn’t really a Neat Concept from a bygone era. When I wrote PPIPC for the Amiga, I had dreams of small efficient programs communicating with each other to cooperate on bigger tasks, and I guess the Binder sort of follows the same vision. But things haven’t turned out that way. Instead we have giant apps that try to do everything you might want (and a hundred other things you’ll never be interested in!) And scripting is something that programmers do;. Most users just want to click a button and have the app do the Right Thing. They don’t want to be bothered to learn how to write scripts for gosh sakes!

I can think of some places I’d like to have IPC (of which scripting is, I suppose, just one aspect). For instance it would be nice to be able to start (and stop) some media playing from some external entity – even say a footpedal, when I’d like to play along with it on my piano. But for most of what we seem to use computers for – writing text, drawing and painting stuff, surfing the web – direct interaction is key, so there’s not much opportunity for IPC.

It might be nice to bring OpenBinder into Haiku, and see what it might be useful for. I’ll have to dig into Android and see how they use their derivative there. (My interest may be more immediate when I get my Gemini in a few weeks!)

Re PhotoShop, my understanding is that JavaScript is an internal feature. I.e, you can write a JS that PhotoShop will itself load and execute – either by command or by triggering event. This is not quite the same meaning of “scripting” as the IPC of the BeOS or Port-Based schemes.

According to their help page, external scripting messages are different – supported by COM in Windows and AppleScript on Mac. Overall, I wonder how often either mechanism is actually useful. (The “snowflake” example in the article you mention is cute, but hardly generally essential!)

OTOH, I can see how JavaScript notation could map onto the BeOS specifier stack. The ‘period-chained’ name (“window[0].view[3].name” or whatever) seems to be a common convention in a lot of places these days. And of course that’s exactly what JSON (as JS-related) uses. I think I’d rather not restrict scripting to a particular language (preferences can be extreme! :slight_smile: ), but I guess the notation could be crross-language.

I know that it was one of the things being worked on at Be, carried on to Palm, and eventually ended up being open sourced and then reused by the same engineers in Android. Is there more I should know?
Still, it never ran on Haiku even if it has BeOS roots. BeBREXX predates it and has an even longer legacy on Amiga, and is already available and usable.

Yes, the OpenBinder is a lot more than a mere IPC. A lot of people think it’s just an IPC because the Android devs used only this part to build their API. The IPC is probably the less interesting feature if seen from the BeOS perspective.

The OpenBinder is in fact, an advanced version of what would have been the BeAPI v2. Not everything is there, different parts like the media and drawing API were trimmed down. But look at the source and you can clearly see that it looks like an advanced version of our kits.

I will list the most interesting features compared to our current API :

  • Introduces the IDL (Interface Description Language), it’s something that fill an hole when it comes to using C++ for a system wide API.
  • Various concepts which in BeOS were just stubbed and/or mixed with ugly C structures become more generalized and interoperable.
  • Loopers aren’t anymore the center of the world, which is in my opinion one of the major flaws in the BeOS API. We absolutely need classes like BThread and so on.
  • Introduces smart pointers and other facilities to ease handling memory.
  • Defines a pattern to work with local and remote objects in an elegant way.
  • Introduce Contexts, if you ever programmed on Android you know what I mean and how those are important.

Going a little bit off topic, I think the only way for us to get to a modern R2 API is moving our R1 API on top of the OpenBinder design. That doesn’t mean necessarily using any code from it, but learning from what the Be Engineers designed to be the future BeOS API.

There are more considerations to do, but I will return back and state what’s very interesting about the binder.

Like the name suggest, one of the major intentions when they designed it was to make creating binding for other languages easy. That’s the biggest reason the Android devs used it, they use the same mechanism to bind their Java API to C/C++ libraries.

Now, the moral of the story, the engineers rather than creating a language like REXX, overly complicated protocols based on port/messages, and other devilry…they created an API which can be easily binded to other languages. It may be to a certain level (at least fundamental operations like messaging) possible to just generate bindings for other languages.

That’s why I suggested to look at it. Often we argue we try to do things the best way possible from the begin, right? Then if we want to supply a scripting interface we should do like the Binder does and additionally we will have all the benefits that comes from.

1 Like

Again, you don’t know what the Binder purpose is.

You got the point…we can use IDL to generalize C++ bindings and then you can use any language to script and program. The whole point is to avoid creating a scripting language/protocol, but making the API accessible in the right way.

Then please educate me.

Like written above, IPC is just one ingredient of the Binder and in my opinion the least important. It’s more important to look at how they planned to abstract interfaces and ease the creation of binding between different languages.

Right, scripting is about IPC, and a somewhat separate issue from language bindings.

A Neat Concept from another era isn’t going to generate much of a frenzy on Haiku right now, because Haiku isn’t in a phase where that’s going to happen for anything.

I think I’ve mentioned before, if there’s an application that could add useful scripting, it might be the browser. Can we use the browser in automated procedures, that would be impossible or at least much harder in curl? Can we use scripts that make browser sessions more productive? That’s the modern super-application, the application environment adopted as a platform for other applications (google.) Open that up to scripting in a useful way. Figure out what that would look like.