Hooks in Base Code
Kero van Gelder
kero at chello.nl
Wed Jul 25 01:06:46 CEST 2007
>> Adding dbus support is *not* the hard part, that's getting calls
>> working at all (and of course all the nifty things you'd want to
>> plug in, but those are outside of the scope of the base infrastructure).
> I agree that adding D-Bus support is not in itself difficult, but trying to
> put the 'right' system in place is not trivial. You cannot broadcast a
> D-Bus method so you need some sort of mediator in the middle (you could
> broacast a signal but that's fire-and-forget so you then have no idea if
> anyone is even considering replying). As such you need a central
> arbitrator to handle this functionality.
Seems to be.
"priorities" and "add at begin of queue" are lovely technical terms
(and I understand where they come from), but esp the last one I'm not
sure will solve any problem at hand (or at least I do not have such a use
I like to program from user requirements;
I can fill in the necessary technical requirements easily.
> I've been playing with some code locally in the last few days to get my
> head around this idea, and will write up a few use cases on the Wiki so
> that everyone can see where this is heading.
I'd like to see many, many use cases, before we pin a
protocol down into a multitude of daemons, modules and whatnot.
I had less time over the weekend than I expected, but here is the fruit of
my labor. Not finished, but Open Source is release early, release often.
This code is targeted at:
- playing around esily (easy API, admit ten lines in agenda.rb is easy :)
- on any dbus/linux device (so play with it on your desktop)
- correctness (unit tests at dbus level provided)
Publishing an API does not work, however. I'll have to grasp some DBus things
for that, I guess...
(and I've got to reread the service/path/interface/destination stuff; I'm
sure I'm messing things up with those)
You'll need the normal Ruby interpreter and at least one gem installed.
Comments welcome! I'll leave it to your choice, whether you reply to the ML
or to me personally (or try to reach me on the IRC channel).
> I understand and agree that making/receiving calls is the most important
> thing right now for the core team but I and no doubt most of the rest of
> the people outside of the core team can't help much there, so if there is a
> way of them being able to build extensions to the will-be functionality
> without getting in the core team's way it should help all round.
Well, if gsdm talks AT-commands... to what will it talk on an incoming call?
The thing that lisens, we can program :)
More information about the community