Hooks in Base Code

Jeff Andros jeff at bigredtj.com
Fri Jul 20 05:57:17 CEST 2007


On 7/19/07, Jim McDonald <Jim at devzero.net> wrote:
>
> kero at chello.nl wrote:
> > OK, first time you mentioned Firefox, I thought you meant browser and/or
> GUI stuff. But you focus on extensions/plugins :)
> >
> Sorry yep was thinking of the design philosophy rather than the
> specifics.  If I look at my own install I have four of five extensions
> (out of a few thousand) that I use and their cumulative impact is to
> make Firefox far more useful *to me* than any other browser out there on
> the market.
> > Any place where you can hook in little snippets of code will do. I think
> I'll play with a few "modules" I can see interact here (addressbook, agenda,
> IM client (mostly its away settings); I'll mock them for starters) and how
> to aggregate the "decisions" from those "modules" on what to do with an
> incoming call/SMS/... I will use dbus, but that says nothing about the
> actual format/info sent over that bus. I'll be off-line over the weekend,
> but with some luck, I'll have a bit of code (i.e. showing format/info) to
> show Sun or Mon.
> >
> Yep I think I'll see if I can grab some time over the weekend to put
> together some words and diagrams explaining what I'm thinking about and
> how it would fit in to the general 'phone framework.
>
> Cheers,
> Jim.


ok, but here's the thing with having full plugin framework: what if two
plugins take mutually exclusive actions (I.E. one plugin has a whitelist, it
tries to answer the phone because it's the girlfriend, but the other plugin
attempts to send the call to voicemail because your gps says you're in a
movie theatre) who should win?  I think we need to take one step beyond
independent plugins:

When the  event is fired, it notifies all the plugins that the event has
fired.
each plugin checks what it thinks should happen, if it's an event that does
not require "taking over" the call, it performs it's action and exits with a
priority 0 (or <0... it's more "unixy") if the plugin thinks it should have
control of the call, it returns with a positive value.
once all plugins have performed their checks (these should be FAST!!! DO NOT
CODE CRAZY ACTIONS HERE!!!) each plugin's score is weighted (whitelists are
modified *2... movie theatre is modified *1.5), weights being user
configurable, then whichever plugin has the highest total score gets control
of the call... it can then take whatever actions it needs to.

There should be a couple of callback functions for those crazy actions that
would take too long to run during the check ones I see are:
setCallBackAfterCall() -- fires a handler after the call has been finished (
I.E. after you hang up, or after the call is rejected).  This is where the
"send text message" would be processed, since we want to wait until the
network is available again
setCallBackAfterProcess() -- fires a handler after someone "wins" the
call... this is where you'd put things that aren't network dependent, and
can happen while the call is getting processed (I.E. while you're talking to
someone)

I'm kind of at a loss in how to create a really nice gui for this kind of
stuff... and events aren't limited to just incoming calls of course... but
yeah, it gives us a really nice way to handle calls

_______________________________________________
> OpenMoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>



-- 
Jeff
ASU Alumni 07
Go Devils!!!
O|||||||O
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/community/attachments/20070719/a661a7a2/attachment.htm 


More information about the community mailing list