Re: External Handler Proof of Concept
>> 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 community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: External Handler Proof of Concept
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
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: External Handler Proof of Concept
>> I'll think about the extension concept a bit more. The fact that you chose
>> a scenario to modify a phone number is interesting. How about calling a
>> person from a Contact? and then choosing VoIP or GSM by those extensions?
>> (specifically, I do not think gsmd is the place where the call should
>> originate, in the image you have on the Wiki).
[snip reason]
> That said, I agree that you would probably want to put another (similar)
> extension method in to the dialer. If you had such a method in the dialer
> then it could tell the dialer to initiate VoIP rather than GSM, in which
> case the GSM extension method would never be called as you wouldn't go down
> that codepath. The more extension calls we have the more flexibility we
> have, although there is a balance between having them everywhere with
> no-one knowing to which one they should attach their extension and having
> them in very few places thus limiting the ability to extend the base
> product.
Indeed, we'll need more than one place to hook in, but not too many places.
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).
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?
> In terms of bindings, what I really need to do is put together the D-Bus
> methods to register/unregister an extension and for the extension handler
> to call the extensions dynamically. At that stage you'll be able to
> integrate your Ruby code very easily. I'll give it a crack over the next
> couple of days and see what I can put together. Watch this space, as they
> say...
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 :)
update on http://chmeee.dyndns.org/git/?p=dbus/.git;a=summary
Bye,
Kero.
require 'dbus/connection'
# become GSMD
DBus.freedesktop.demand_name("org.openmoko.GSMD")
# We'll be wanting to look in the Contacts, make a "proxy" (dbus terminology)
contacts = DBus::Proxy.new(DBus.session, "org.openmoko.Contacts",
"/org/openmoko/Contacts", "org.openmoko.Contacts")
counter = 0
loop {
counter += 1
phone_number = (1024_000+counter).to_s
# pretend there is an incoming call
DBus.session.emit("org.openmoko.Call", "Incoming", "s", phone_number)
# Look up the caller ID in the Contacts
p contacts.call("WhoIs", "s", phone_number)
sleep 1
}
require 'dbus/match_rules'
DBus.freedesktop.demand_name("org.openmoko.Contacts")
DBus.session.listen_for(DBus::Interface=>"org.openmoko.Call",
DBus::Member=>"Incoming") {|msg|
puts "Incoming call from #{msg.body} !"
}
DBus.session.publish_method("org.openmoko.Contacts", "WhoIs") {|msg|
DBus.session.reply_to(msg, "s", "John")
}
sleep 1234567890
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: External Handler Proof of Concept
Kero van Gelder wrote: [...] I'll think about the extension concept a bit more. The fact that you chose a scenario to modify a phone number is interesting. How about calling a person from a Contact? and then choosing VoIP or GSM by those extensions? (specifically, I do not think gsmd is the place where the call should originate, in the image you have on the Wiki). The reason why I chose the gsmd in the example is because it is the final action prior to actually making the call and as such it is a good place to make changes that you don't want seen by the higher levels. For example, say you wanted to call +1-555-123-4567 but the calling card extension decided that the number that you actually need to dial is +1-800-800-8001,555-123-4567 you do not want the latter number showing up in the journal, last call lists, etc. That said, I agree that you would probably want to put another (similar) extension method in to the dialer. If you had such a method in the dialer then it could tell the dialer to initiate VoIP rather than GSM, in which case the GSM extension method would never be called as you wouldn't go down that codepath. The more extension calls we have the more flexibility we have, although there is a balance between having them everywhere with no-one knowing to which one they should attach their extension and having them in very few places thus limiting the ability to extend the base product. In terms of bindings, what I really need to do is put together the D-Bus methods to register/unregister an extension and for the extension handler to call the extensions dynamically. At that stage you'll be able to integrate your Ruby code very easily. I'll give it a crack over the next couple of days and see what I can put together. Watch this space, as they say... Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: External Handler Proof of Concept
> I was playing around with the extensions framework > (http://wiki.openmoko.org/wiki/Wishlist:Extension_Framework) over the > weekend and have put together a proof of concept for the idea. The > packages are not currently designed to run on the openmoko or integrate > with the build process but on a standard linux distribution (until I get a > 'phone, anyway). The distribution consists of three separate packages: > >* openmoko-extensionhandler - receives extension requests and passes > them through the chain of extensions registered for that request >* openmoko-extension-sample - sample extension that changes the > parameters of an outgoing call >* fakegsmd - simple client that generates an extension request for > an outgoing call (as would be expected to be generated by gsmd) [snip] > Anyway, if people would like to take a look at this it is available at > http://www.devzero.net/openmoko/dist/omext.tar.gz - please give it a go and > let me know what you think. Compiles, works. Probably a nice idea to see if I can get my Ruby code to talk to yours :) Ah, ListNames spots ["org.freedesktop.DBus", "org.openmoko.ef.eh.Gsmd", ":1.17", ":1.18"] so I guess that should be easy enough :) And I'm trying to do the equivalent of this in Ruby, but failing: /* Start repeat for each handler */ obj = g_object_new (EXTENSIONHANDLERGSMD_TYPE, NULL); dbus_g_connection_register_g_object (connection, EXTENSIONHANDLERGSMD_PATH, obj); (NB: there's nothing repeating there. adapt comment, pls) I'll use dbus-monitor on your code and learn :) I'll think about the extension concept a bit more. The fact that you chose a scenario to modify a phone number is interesting. How about calling a person from a Contact? and then choosing VoIP or GSM by those extensions? (specifically, I do not think gsmd is the place where the call should originate, in the image you have on the Wiki). That is it for now, Bye, Kero. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
