views:

96

answers:

3
A: 

I'm not exactly sure what you mean by "scriptable". Do you mean you want it to have an external interface (sort of like an API) which other programs/scripts can access? If yes, then I think your best bet is to use sockets (either Unix or TCP). They're as cross platform as it gets and most scripting languages have some way of communicating through sockets (I've played with them in Python, PHP and Java).

As a side note, if you decide to go with sockets, it would be nice to implement some sort of standardized protocol, such as XML-RPC over HTTP. This would make your "API" much easier to use.

Again, I hope I understood what you meant by "scriptable". If not, just disregard my answer.

Felix
+3  A: 

You may find D-Bus useful. It provides an object-oriented API with activation support.

Ignacio Vazquez-Abrams
Definitely would go with D-Bus based on those needs. Check [https://fedorahosted.org/d-feet/] as a useful tool for inspecting existing D-Bus APIs, and testing whatever API you develop.
Pete
Can you recommend a scripting language with a clean D-Bus binding? The ones I've seen are very low-level. I'd like something that can treat a D-Bus object like a native object and transparently translate object methods calls into D-Bus method calls.
arx
Unfortunately they're all pretty low-level. I agree that it would be nice to have transparent proxies for this, but I've not seen any.
Ignacio Vazquez-Abrams
Do you know of an application that exposes a complex object model over D-Bus so I can see how it's done and how easy (or not) it is to script it?
arx
Let's see here... On my system I see hal, NetworkManager, Avahi, bluez... Just fire up a Fedora or Ubuntu system and you'll see about a dozen you can poke through.
Ignacio Vazquez-Abrams
+3  A: 

The usual way is to expose some CLI commands and allow users to use them in whatever shell/script language user writes; see f.e. imagemagick, which exposes a number of commands to convert images between formats and apply transformations. This works well in any OS.

This can also work with interactive programs, although it is rare. You can use D-BUS interface (which gets more and more popular in both GNOME and KDE), although it is more for processing events or sending simple commands. You might want to make an interactive or daemon-like program which exposes D-BUS (or even simple socket/pipe-based) interface, plus some simple CLI calls that wraps sending commands so that the interface is much simpler. See moc/mocp ("Music On Console Player") or xmms2. This works well in any OS, but usually needs some time to work out implementation details on different OSes.

Do not fear embedding a full language. Languages like Lua or Guile were designed so that they are very simple to embed and pretty powerful. Standarizing on one such language is not always a bad thing, as this means more code reusability between users... and the language actually matters only if you plan users to write big pieces of code as plugins.

There are some ways to expose API to several scripting languages using special libraries. You can read about them f.e. here: Kross@Wikipedia. I have no experience with them.

I assume that your program will be closed-source... Then last option I can see is to expose some kind of API/ABI interface which can be used by users' C programs (f.e. compiled to dynamic library). This way users will be able to make wrappers for any language they want, plus they can make code in plain C for speed. This solution might be difficult to make portable, but it gives you (and your users) flexibility.

Note that it is easy to overdesign scriptability: it is better to leave programming constructs to external languages, and only provide simple means of interaction with your program. I have seen programs which added their own looping facilities to a scripting languages, even though they didn't add any value to user: f.e. ability to pass multiple images to convert at once, even though it didn't make processing faster.

liori
Thank you, I've added more detail in the question.A CLI is inappropriate because the data is too fine-grained. Script code needs to be able to inspect and manipulate it.The D-BUS clients I've looked at have very clunky interfaces. You have to make explicit D-BUS calls rather than simply manipulating objects in the scripting language.Kross looks like overkill (why is it necessary to embed anything?) but it's the closest answer to what I had in mind.A C interface is possible, but very clunky for a complex object model and requires lots of glue code for different languages.
arx
Well, I don't know very well how does COM work. I can only suggest you to try `Lua`; its overhead is very small, its object model very simple, so that even if your users really need to use another language, they will have easy way to interact with your program using Lua API calls... and then you can probably treat Lua as some kind of COM-like glue.
liori
I've spend another day looking at D-Bus but it still doesn't seem like a good fit. Kross is better so I've marked this as the answer. Thank you.
arx
+1, good response, only mentioning SWIG would have made it even better ;-)
none