>> 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 ;) _______________________________________________ OpenMoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
