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