External Handler Proof of Concept

[Jim McDonald]

Kero van Gelder wrote:

> Something I thought of, the application (or whatever) that might want to
> register an extension need not be started yet. After all, DBus is capable
> of starting applications (and I'm sure Contacts, Agenda and a few more
> will be in the nearby future).
>   

Yep I'm planning on adding in service files when I get hold of a real 
'phone to work with.

> So at least for choosing VoIP or GSM, the system-dbus must tell what's
> available and Contacts must tell how we can reach the person at all.
> I think *calling* Contacts is more suitable than letting it register an
> extension, for this case.
>
> What do you think?
>   

Not sure, it may be that there is a 'routing' extension that takes 
information about what call to make and works out the method to send it 
with.  Of course, a lot of this type of functionality is being built in 
to the core applications so it will take some untangling.  I think that 
until there is at least a skeleton set of applications in place it will 
be hard to work out the linkages from one item to another and how it all 
hangs together.  The example above is a case in point, where handing off 
the call information from the dialer to the gsmd (or wherever) is not 
something that I had originally envisaged would be part of the 
extensions framework but it could be if the rest of the pieces are coded 
in a suitable fashion.  Definitely a wait-and-see.


[...]
> Same here, polished my code, you can now use it like in the two little
> attachments. It's not as clean as Ruby can be, yet, but it's rather close
> now. I'm also happy to have freedesktop.* in a separate file, now.
>
> I bet I can
>   ext_handler = DBus.proxy.new("org.openmoko.ef.eh.Gsmd", "/org/openmoko/ef/eh/Gsmd/, "org.openmoko.ef.eh.Gsmd")
>   ext_handler.call("method", "sig", arg0, arg1, ...)
> already :)
>   

Not any more you can't :)

So thanks to a long flight I had a chance to tidy up the code and put 
some registration methods in place.  I also renamed some of the 
interfaces and paths because it looks like I'm ending up with a single 
process for both registration and handling of specific calls.  The 
latest code is at http://www.devzero.net/openmoko/dist/omext.tar.gz  I 
have also updated the Wiki at 
http://wiki.openmoko.org/wiki/Wishlist:Extension_Framework

The key difference is that you can now register your own extension by 
sending a method call org.openmoko.ExtensionHandler.Register().  Details 
of the parameters are up on the Wiki.  Note that registrations are 
persistent so once you have registered you will remain so unless you 
send an org.openmoko.ExtensionHandler.Unregister() with the same 
parameters as you used to register.  This also means that extensions can 
be written in any language (for example, Ruby :)) and do not need any 
information hard-coded in to the extension handler itself.

At current I'm using gconf as a backend so if you do want to see the 
results of your registration attempts you can do so by running 
'gconftool-2 -R /extensions'.

Have a play and let me know how it goes.  Still lots to do but it's 
starting to take some shape.

Cheers,
Jim.