Hi,
while I am adding scripting support to the mobile application I tried using a primitive
interface between the scripting implementation and the mobile application. On new
indications a callback in the primitive interface user will be invoked and there is a
generic submit function that will dispatch (switch/case) over the primitive and call the
right internal functions. To prototype this I have implemented "timer" support,
SMS and the started/shutdown handling through primitives.
The neat thing about this approach is that I don't tie a specific scripting solution
into the code, the indications are generic enough to be useful in multiple contexts, the
submit/dispatch is about high level operations ("send SMS", "switch device
off") that map to other programming languages as well. E.g. it is easy to imagine
that one writes a TCP/IP adapter to send these primitives to another process/application.
The controversial part is that this code is not using a msgb. Normally the primitive
header is inside a msgb and then more or less points to itself. But in the scripting layer
case the "timer", "new sms", "network selection" are already
fully parsed objects (or where never parsed from a network representation) so are normally
not located in a msgb in any form.
One option is not to bother and deal with the primitive header just being embedded in
another structure. The concept of request/response/indication is bigger than network
messages.
The other is to create a dummy msgb to obey the interface and follow the existing users
but I am not sure what we would gain.
For XYZ->internal we can use direct function calls and avoid the indirection of the
primitives and for indications either call directly into the scripting code or create a
script_indications struct and put it into the struct osmocom_ms. Only downside that doing
RPC requires more work? So far I only forsee a single "script_indications"
callback.
comments? opinions?
holger