External Handler Proof of Concept

[Kero van Gelder]

>> 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.

Technically, I should have had mine already... UPS is not really helpful...
and then I'll be on holiday for two weeks about as soon as i'll receive it...

> 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.

agreed, to some extent ;)
I'll see if I can collect user stories (and put them on the wiki) when I'm back.

> 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.

Compiles.
But the extension handler dies (badly, corrupted stack) when I run fakegsmd.
(debian unstable)
No time to look into the details.

I have a slight update at http://chmeee.dyndns.org/git/?p=dbus
of my own code. Just to let you know I'm still there ;)