Re: Hooks in Base Code
Moin, Am Fri, 20 Jul 2007 09:20:44 +0100 schrieb Jim McDonald: Yep that's pretty much what I'm talking about here. But to do this we will need the low-level code to send us the methods/signals so that we can take the appropriate actions, which is the bit that I'm worried is not being considered and so this type of functionality will just not be possible without being a 'core' developer. Don't worry too much about that right now. I don't know what the current plan for this problem is but, given that OpenMoko already uses dbus, I'm quite sure that it will include dbus. Going from I have an application that, when a call comes in, pops up a dialog and asks the user to accept or reject the call to I have an application that, when a call comes in, broadcasts a dbus message 'There's a call from ..., anyone want to handle that?' and waits for a reply ... 'Anyone? Anyone? Ok, openmoko-dialer, your turn'. is easy. 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). For an example how something like that could look like look at the new bluez dbus infrastructure, for example regarding pin-entry: It can be a simple C program that always returns the same pin, but it could also be python script that switches on the coffee machine, cleans the cat litter box, makes breakfast, and then uses the lottery numbers from the newspaper as a pin. And yes, for OpenMoko that explicitly includes sending an SMS or anything else that you might want to do. Just code it, in the programming language of your choice. (Note again that I don't know what the current plans are, but even in the unlikely case that nobody from the core team yet thought about using dbus for call handling it's probably easy enough that *someone* will do it.) -- Henryk Plötz Grüße aus Berlin ~ Help Microsoft fight software piracy: Give Linux to a friend today! ~ ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
Henryk Plötz wrote: Don't worry too much about that right now. I don't know what the current plan for this problem is but, given that OpenMoko already uses dbus, I'm quite sure that it will include dbus. Going from I have an application that, when a call comes in, pops up a dialog and asks the user to accept or reject the call to I have an application that, when a call comes in, broadcasts a dbus message 'There's a call from ..., anyone want to handle that?' and waits for a reply ... 'Anyone? Anyone? Ok, openmoko-dialer, your turn'. is easy. Only if it isn't already hard-coded to go to the dialer in the first place, which is why I'm bringing this up now. 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. 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 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. Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
Jim McDonald [EMAIL PROTECTED] wrote : hat everyone can see where this is heading. 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. There's two approaches, get the core functionality working solidly first. Then create the hooks and extensibility. Second is to do both concurrently. Each approach has its advantages. --- G O Jones ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
Hi, Here is my two cents worth. I also hope what i am saying here is not too basic and is comprehensible. I program in Forth so my knowledge of C vocabulary is not fabulous. On Sat, 2007-07-21 at 12:28 -0400, Clayton Jones wrote: I like the ideas presented here, but i have some experience designing building real time embedded systems so some points to think about: I too have a long history designing, building and writing code for real time embedded systems and all my current designs implement a similar strategy of having Event Generators (usually interupts), an Event Dispatcher and Event Handlers. IMHO the Event Router should be as simple and fast as possible. Any complex sorting/ checking of event lists etc etc should be left to code sitting on the sidelines 1) The Event Router should also have some sort of priority mechanism ... How about a linked list of Event Objects which would contain the Link to next Event, Event Priority, Event Parameters and Link to a specific Event Handler. The Event Router would pass execution to the specific Event Handler for the Event Object at the top of the list. When the specific Event Handler had finished it would pass control back to the Event Router which would delete the finished Event Object and move on to the next in the list. The Event Handler could simply be a list of calls to various code. This list could be easily edited to change the functionality of the device. Would have to have a mechanism for handling errors. Rather than having fixed Event Parameters i would go for a Parameter Heap which would be part of the Event Object. It doesn't need any fixed format as both the code that generated the event and the Event Handler know what the parameters are. To generate a new event one creates a new Event Object with say one of three functions CreateEventAtTopOfList - Would be used if immediate execution is needed CreateEventAtBottomOfList - Execute when you have time CreateEventInMiddleOfList - Insert in execution list, location dependent on Event Priority 2) We have to be careful about race conditions in event notification latency and order. This sequential execution of the Event Objects should reduce the chance of race conditions but will mean that the Event Handlers will need to execute expeditiously so as not to hold up the Event handling system. Other code could sit on the sidelines keeping track of the event list to make sure nothing is going wrong. 3) Finally, we have to keep in mind that this is a small-form factor, battery-powered system - we'll always be behind on the power/resource curve from our desktops, so we have to be aware of speed and resources. I couldn't agree more. I have seen a number of engineering projects fail due to overcomplexity and inattention to low level design resulting in unacceptably slow response and too much power consumption. If anyone thinks this is a good idea i will flesh it out more in the wiki. Regards Simon Matthews ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
Hans L wrote: Hey folks, Great discussion going on here. I've been putting a lot of thought into the issue too, so I figured I'd add my two cents. [...] Yep this is very similar to what I'm thinking of. Given that we're all pretty close to what we think we need it's probably time to put something on the Wiki. I've put an initial page at http://wiki.openmoko.org/wiki/Wishlist:Extension_Framework so if people can make any additions that they wish there it would be easier to track and get us to the stage where we can get the buy-in of the openmoko team and start laying down some code. There are a few things that you mentioned here that I haven't yet covered in the Wiki such as profiles, use of the configuration GUI and the like so if you want to flesh them out on that page it would be much appreciated. Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
Jim McDonald wrote: Giles Jones wrote: Jim McDonald [EMAIL PROTECTED] wrote : This is why you send the event to the notification system and then wait for the response. The notification system would read the users rules and act appropriately. For an incoming call if you had a rule which says you are busy then the process would be as such: 1.Phone process receives incoming call event. 2.Phone process sends call details and incoming call event to notification system. 3.Notification system checks user settings. Agree up until now, but this is the bit where we diverge; I believe that if done properly there could be any number of responses to the fact that there is an incoming call, and they won't all fit happily in to a simplistic event code model. Let's pick a simple example mentioned earlier on the list, where the 'phone is set to reject all calls but if someone calls three times in five minutes then you want to make the 'phone ring because it may be urgent. Now, the really important bit here is not the technical details of how it accomplishes the requirement but the fact that it is highly questionable if you want to put this type of functionality within your base 'phone. It being just one of no doubt 100 esoteric features that end users will come up with you don't want to be faced with a massive set of options or a slow 'phone because it's checking so many things every time someone calls you. You want this to be a much more flexible system, and to do that you need to think of the 'notification' system as a central messaging hub where it can pass on the fact that there is an incoming call, along with the details of that call, to any module that The diversity seems base on assumption that notification system will broadcast the event and allow multiple response from different modules. What about using a system similar to iptables? Each module only provide function to match against some call info. Some target actions are defined by the notification system. And rules is setup by user so that when a call event come in, the notification system can check the call info against the rules one by one until one is match and do the target action in that rule. Normally each target action will do their jobs and then terminate the matching process. For more complex situation, target action may allow continue of the matching process (e.g. call history logging or send out sms), but this own exist when both the module is allow and user have add addition option on that target action. This should cover all condition which can be represent by AND/OR logic and is easy to implement. The only drawback is the rule setup interface may not be friendly enough for normal user. Regards, Henry ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
Henry Law wrote: What about using a system similar to iptables? Each module only provide function to match against some call info. Some target actions are defined by the notification system. And rules is setup by user so that when a call event come in, the notification system can check the call info against the rules one by one until one is match and do the target action in that rule. Normally each target action will do their jobs and then terminate the matching process. Yep that's pretty much what I'm talking about here. But to do this we will need the low-level code to send us the methods/signals so that we can take the appropriate actions, which is the bit that I'm worried is not being considered and so this type of functionality will just not be possible without being a 'core' developer. Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
Jeff Andros wrote: 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: This could be handled through either ordering or priority, either would work. There still needs to be a control center that receives the basic message from the core code (e.g. incoming call), works out which modules are interested in the message and then sends it on to them. If you are using ordering then you would probably chain the messages so that if the message was altered by one module the altered message would be received by the next/./ If you were using priority then you could send the message to every module at the same time and wait for all responses before continuing. Ordering would probably be easier both to develop and for end users to manage. Priorities *may* by faster, although that's not guaranteed by any stretch. The best solution would probably be a combination of ordering and priorities. As you mention, although this would be a very useful system a lot of the ability of it to be end-user friendly would rely on a very intuitive GUI (or alternatively a system that is restricted in such a way that a configuation GUI is not required). ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
Jim McDonald [EMAIL PROTECTED] wrote : which is the bit that I'm worried is not being considered and so this type of functionality will just not be possible without being a 'core' developer. I don't think the project will last long if there's too much snobbery about who does what. By all means reject bad code, but don't create a closed off team like XFree86. We don't want someone forking the project creating confusion. --- G O Jones ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
Giles Jones wrote: I don't think the project will last long if there's too much snobbery about who does what. In this case it isn't snobbery so much as ensuring that there is a simple way to put the right functionality in the right place. Overloading gsmd with lots of (potentially conflicting) user requirements would lead to code that was hard to maintain and with a steep learning curve, hence the point that only those who put the time and effort in to understand all of the wrinkles would be able to make safe changes, and these people would be 'core' developers purely because that's where they would have to do the development to get the functionality they required. 'core' isn't a synonym for 'better' here, it just refers to developers that work on the core functionality of the product rather than the (in my opinion) more interesting stuff of the higher-level applications. Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
1) How would you put that in an engine? Where does all the relevant info come from? 2) Then build aan interface to allow an end-user to create such rules. 3) And finally do something trivial with dbus, commandline (or even XML...) to play the appropriate ringtone. and show an Pickup/Cancel pair of buttons. there was some talk about this back in january or so... it got even more involved than that: if the addressbook says I'm supposed to be sleeping, but the lights are on (maybe later we'll have an ambient light sensor) there's lots of noise, the GPS shows I'm at a club, and the accelerometers detect movement (those are going to be so cool) I'm probably not sleeping, go ahead and ring (is it too tacky to list attendees for sleeping maybe you don't want it to ring, but anyways) Fun, I'll dig in the archives :) the talk kind of centered around a nodeset somewhere in the filesystem, but from what I've seen on dbus that might be a better solution. basically, you create a group of modules, each of which is queried for a result... then each contact is matched against a set of rules based on the set of results. A module / rule hierarchy. Would that fit the exception-on-exception kind of rules we've been mentioning? I guess it could/ on call importance, you can also list call frequency for the contact (I.E. if john calls me 3 times in 5 minutes, it's probably something important... ring on the third attempt) oh, greylisting :) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
Jim McDonald [EMAIL PROTECTED] wrote : Yep that's roughly what I'm talking about but we need the base code to be set up such that it will make those calls and pay attention to the results, which is the main thrust of my argument. All the code should need to do is talk to notification process, fire off an event, listen for a result and then act on the returned ID. Example: Incoming phone call. Phone process would send the event code to the notification system, the notification system would look at rules for this event, see if it matches any and if so return the action to the process. So if you have configured calls to be forwarded, the notification system would return an action that the phone process needs to forward the call. The notification system would then write an entry in the call history to say it had been forwarded and popup a little message box on the screen just incase anyone is looking. I would imagine all of this is pretty standard stuff, you wouldn't want to hold up a phone call by having the phone process create a sub process to display a message box etc.. --- G O Jones ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
Jim McDonald [EMAIL PROTECTED] wrote : Well yes, that's really what I'm talking about. But there are also other things that some people may want to do with an incoming 'phone call that we won't think about. Perhaps send an SMS to another 'phone to say that a call was received? Just an example, but the point is that we won't be able to know in advance all of the things that someone may want to do when a call comes in This is why you send the event to the notification system and then wait for the response. The notification system would read the users rules and act appropriately. For an incoming call if you had a rule which says you are busy then the process would be as such: 1.Phone process receives incoming call event. 2.Phone process sends call details and incoming call event to notification system. 3.Notification system checks user settings. 4.Notification system returns busy event code to Phone process. 5.Phone process plays busy tone and hangs up. 6.Notification system logs the missed call and does any other configured actions (send SMS, play a sound etc..). I know that there are many possible actions, but each phone component will only have so many possible actions. A phone process will only ever have a few events, pickup, hangup, play tone, hold, conference call etc... When the processes register themselves with the notification system they will send a list of the supported events to it. --- G O Jones ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
Giles Jones wrote: Jim McDonald [EMAIL PROTECTED] wrote : This is why you send the event to the notification system and then wait for the response. The notification system would read the users rules and act appropriately. For an incoming call if you had a rule which says you are busy then the process would be as such: 1.Phone process receives incoming call event. 2.Phone process sends call details and incoming call event to notification system. 3.Notification system checks user settings. Agree up until now, but this is the bit where we diverge; I believe that if done properly there could be any number of responses to the fact that there is an incoming call, and they won't all fit happily in to a simplistic event code model. Let's pick a simple example mentioned earlier on the list, where the 'phone is set to reject all calls but if someone calls three times in five minutes then you want to make the 'phone ring because it may be urgent. Now, the really important bit here is not the technical details of how it accomplishes the requirement but the fact that it is highly questionable if you want to put this type of functionality within your base 'phone. It being just one of no doubt 100 esoteric features that end users will come up with you don't want to be faced with a massive set of options or a slow 'phone because it's checking so many things every time someone calls you. You want this to be a much more flexible system, and to do that you need to think of the 'notification' system as a central messaging hub where it can pass on the fact that there is an incoming call, along with the details of that call, to any module that may want to do something with it. The other key thing to realise here is that each of these modules will be a nice and simple beast that understands its own job and neither knows nor cares about what is going on elsewhere in the system. Writing a piece of code that will carry out the above function is simple, but if it was to be inserted in to gsmd (or the notification system) then it would be a much bigger task as you need to understand how the existing system works, where your code fits, write something, send it in as a patch, get it reviewed, and finally in the next major release of the software it will show up. (Also bear in mind that incoming calls are a very simple example as there is not much that I can think of doing with them off-hand. However, if you start to think about outgoing calls there are many more things that you may want to do, including allowing/not allowing the call (for child or business 'phones), routing the call through another system (calling cards), sending/not sending your caller ID with the call, allowing/not allowing calls to call anyone not in your address book, only allowing non-business calls outside of business hours, who knows? The point is that every time we build a static code path we're limiting the ability of the next person to do something we didn't think of, which makes the whole thing less free than we would like. I'd again say to look to the Firefox extensions system as a good example of where this has worked well, and not only gives people lots more freedom in how they surf the web but has made the browser far more powerful (and successful) that it could have been with any single set of developers while at the same time making it easy for outside developers to add to the product with minimal, if any, knowledge of the existing codebase. I think that is the model that openmoko should be trying to emulate, otherwise we'll just end up with an open source 'phone with all of the inflexibility of a closed source 'phone (to the majority of people that might use it), and that doesn't seem to be a great leap forward from where things are today. Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
(Also bear in mind that incoming calls are a very simple example as there is not much that I can think of doing with them off-hand. Just heard a news-item on the radio: a service where you don't get commercial calls during dinner, implemented at the side that calls you. Messy (companies do not have to implement that service). I really think you need to solve this phone side; guess what OpenMoko can do :) Just another example; now back on-topic... The point is that every time we build a static code path we're limiting the ability of the next person to do something we didn't think of, which makes the whole thing less free than we would like. Full ack. I'd again say to look to the Firefox extensions system as a good example of where this has worked well, and not only gives people lots more freedom in how they surf the web but has made the browser far more powerful (and successful) that it could have been with any single set of developers while at the same time making it easy for outside developers to add to the product with minimal, if any, knowledge of the existing codebase. OK, first time you mentioned Firefox, I thought you meant browser and/or GUI stuff. But you focus on extensions/plugins :) 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. Bye, Kero. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
[EMAIL PROTECTED] 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. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
On 7/19/07, Jim McDonald [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] 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@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Jeff ASU Alumni 07 Go Devils!!! O|||O ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
I don't know how much of the at signaling is available at the data terminal. What is the signaling for sending caller ID to a cellular phone? For example, on POTS, the digits are signaled with a Bell 103 modem between the first and second ring. Someone said something about having the ringback tone be a sound file that is configurable according to caller. I don't know if that is possible from the phone. The ring back tone is generated by switching equipment, not the terminal. --Dan On 7/18/07, Jim McDonald [EMAIL PROTECTED] wrote: [This may have been better to post to the development list but as people are talking about it here I'll start here] Hi, A number of people have been talking about the cool things that they would like their 'phone to do but after spending some time looking at the information available so far I don't see anything that suggests the current codebase will allow people the freedom that they need. If I take a simple example of an incoming call them some of the suggestions that we have seen so far to handle it include different ring tones for different people or groups of people, auto-handling of the call by sending it to voicemail or letting it through, different responses depending on the time of day, *etc. *The point that I'm trying to make is that there are a multitude of things that you *could* do but each person will have a limited number of things that they want the 'phone to *actually* do. As such, building out all of these options in to a single piece of code will not only be very hard to manage and maintain but will severely limit the ability of people to scratch their itches and develop code to make the 'phone do what they want it to. If the monolithic approach is out then some sort of modular approach is required. The most obvious example out there today is Firefox, which comes in a relatively simple base configuration but provides any number of hooks to allow people to write their own extensions on top of the base code and as such to alter the functionality of the product very extensively. If we want this openmoko to be as free as possible then it also needs to be as easy as possible for people to extend, and this is the most likely way of doing it. I know that there are a lot of potential problems that need to be addressed when building this out but if there is a vision from the start as to how this would work then it would go a long way to making the final product the 'phone that we are all dreaming of, regardless of the fact that those dreams are often divergent from others if not totally exclusive. So my questions are there plans to include these hooks, and if not can it be considered? Or is there another way to do this other than hooks? Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
Daniel Robinson wrote: I don't know how much of the at signaling is available at the data terminal. What is the signaling for sending caller ID to a cellular phone? For example, on POTS, the digits are signaled with a Bell 103 modem between the first and second ring. Someone said something about having the ringback tone be a sound file that is configurable according to caller. I don't know if that is possible from the phone. The ring back tone is generated by switching equipment, not the terminal. To clarify, I'm thinking not of getting in the way of the basics of things like gsmd, which should handle the fact that there is an incoming call and also pick up the caller ID if present, but what openmoko does as a result of this information. Given the fact that there is an incoming call from number 555-123-4567 what should the 'phone do? Should it silently ignore the call, send it straight to voicemail (either operator or on the 'phone itself), use a specific ringtone for the user, even shut down entirely (some sort of if I ring my 'phone from this number then nuke it option!). The point is, there are lots of possibilities and we don't want them all sitting inside gsmd, it makes more sense for them to be external modules that can be chained together in a clean fashion without requiring direct access to something as sensitive as gsmd. At least, that's my take on it. --Dan Cheers, Jim. On 7/18/07, *Jim McDonald* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: [This may have been better to post to the development list but as people are talking about it here I'll start here] Hi, A number of people have been talking about the cool things that they would like their 'phone to do but after spending some time looking at the information available so far I don't see anything that suggests the current codebase will allow people the freedom that they need. If I take a simple example of an incoming call them some of the suggestions that we have seen so far to handle it include different ring tones for different people or groups of people, auto-handling of the call by sending it to voicemail or letting it through, different responses depending on the time of day, /etc. /The point that I'm trying to make is that there are a multitude of things that you /could/ do but each person will have a limited number of things that they want the 'phone to /actually/ do. As such, building out all of these options in to a single piece of code will not only be very hard to manage and maintain but will severely limit the ability of people to scratch their itches and develop code to make the 'phone do what they want it to. If the monolithic approach is out then some sort of modular approach is required. The most obvious example out there today is Firefox, which comes in a relatively simple base configuration but provides any number of hooks to allow people to write their own extensions on top of the base code and as such to alter the functionality of the product very extensively. If we want this openmoko to be as free as possible then it also needs to be as easy as possible for people to extend, and this is the most likely way of doing it. I know that there are a lot of potential problems that need to be addressed when building this out but if there is a vision from the start as to how this would work then it would go a long way to making the final product the 'phone that we are all dreaming of, regardless of the fact that those dreams are often divergent from others if not totally exclusive. So my questions are there plans to include these hooks, and if not can it be considered? Or is there another way to do this other than hooks? Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org mailto:community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
sure we couldn't do it directly like that. But couldn't we fake it by have the phone answer the call immediately after it detects it, playing the sound file over the radio (instead of sending microphone input), and act like it's still ringing? On 7/18/07, Daniel Robinson [EMAIL PROTECTED] wrote: I don't know how much of the at signaling is available at the data terminal. What is the signaling for sending caller ID to a cellular phone? For example, on POTS, the digits are signaled with a Bell 103 modem between the first and second ring. Someone said something about having the ringback tone be a sound file that is configurable according to caller. I don't know if that is possible from the phone. The ring back tone is generated by switching equipment, not the terminal. --Dan On 7/18/07, Jim McDonald [EMAIL PROTECTED] wrote: [This may have been better to post to the development list but as people are talking about it here I'll start here] Hi, A number of people have been talking about the cool things that they would like their 'phone to do but after spending some time looking at the information available so far I don't see anything that suggests the current codebase will allow people the freedom that they need. If I take a simple example of an incoming call them some of the suggestions that we have seen so far to handle it include different ring tones for different people or groups of people, auto-handling of the call by sending it to voicemail or letting it through, different responses depending on the time of day, *etc. *The point that I'm trying to make is that there are a multitude of things that you *could* do but each person will have a limited number of things that they want the 'phone to *actually* do. As such, building out all of these options in to a single piece of code will not only be very hard to manage and maintain but will severely limit the ability of people to scratch their itches and develop code to make the 'phone do what they want it to. If the monolithic approach is out then some sort of modular approach is required. The most obvious example out there today is Firefox, which comes in a relatively simple base configuration but provides any number of hooks to allow people to write their own extensions on top of the base code and as such to alter the functionality of the product very extensively. If we want this openmoko to be as free as possible then it also needs to be as easy as possible for people to extend, and this is the most likely way of doing it. I know that there are a lot of potential problems that need to be addressed when building this out but if there is a vision from the start as to how this would work then it would go a long way to making the final product the 'phone that we are all dreaming of, regardless of the fact that those dreams are often divergent from others if not totally exclusive. So my questions are there plans to include these hooks, and if not can it be considered? Or is there another way to do this other than hooks? Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
On 18 Jul 2007, at 23:03, Jim McDonald wrote: If the monolithic approach is out then some sort of modular approach is required. The most obvious example out there today is Firefox, which comes in a relatively simple base configuration but provides any number of hooks to allow people to write their own extensions on top of the base code and as such to alter the functionality of the product very extensively. If we want this openmoko to be as free as possible then it also needs to be as easy as possible for people to extend, and this is the most likely way of doing it. I know that there are a lot of potential problems that need to be addressed when building this out but if there is a vision from the start as to how this would work then it would go a long way to making the final product the 'phone that we are all dreaming of, regardless of the fact that those dreams are often divergent from others if not totally exclusive. So my questions are there plans to include these hooks, and if not can it be considered? Or is there another way to do this other than hooks? You have to modularise and split the applications into interface and the engine code as much as possible. If clever enough you could even define the interface layout using definition files in XML or some other trendy file format :) I know that the Home page on Windows Mobile Smartphone edition is just an XML file which can contain links to plugins. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
On 18 Jul 2007, at 23:21, Jim McDonald wrote: To clarify, I'm thinking not of getting in the way of the basics of things like gsmd, which should handle the fact that there is an incoming call and also pick up the caller ID if present, but what openmoko does as a result of this information. Given the fact that there is an incoming call from number 555-123-4567 what should the 'phone do? Should it silently ignore the call, send it straight to voicemail (either operator or on the 'phone itself), use a specific ringtone for the user, even shut down entirely (some sort of if I ring my 'phone from this number then nuke it option!). The point is, there are lots of possibilities and we don't want them all sitting inside gsmd, it makes more sense for them to be external modules that can be chained together in a clean fashion without requiring direct access to something as sensitive as gsmd. At least, that's my take on it. If it's just notifications then you can have a notification daemon which any application can register it's events with. The preferences for this would allow something like Play Sound, Display Message, Flash backlight, Vibrate, Power off, Run script, Run command or do nothing. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
Giles Jones writes: If it's just notifications then you can have a notification daemon which any application can register it's events with. The preferences for this would allow something like Play Sound, Display Message, Flash backlight, Vibrate, Power off, Run script, Run command or do nothing. Note that dbus is already a part of openmoko. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
If the monolithic approach is out then some sort of modular approach is required. The most obvious example out there today is Firefox, which comes in a relatively simple base configuration but provides any number of hooks to allow people to write their own extensions on top of the base code and as such to alter the functionality of the product very extensively. If we want this openmoko to be as free as possible then it also needs to be as easy as possible for people to extend, and this is the most likely way of doing it. I know that there are a lot of potential problems that need to be addressed when building this out but if there is a vision from the start as to how this would work then it would go a long way to making the final product the 'phone that we are all dreaming of, regardless of the fact that those dreams are often divergent from others if not totally exclusive. So my questions are there plans to include these hooks, and if not can it be considered? Or is there another way to do this other than hooks? You have to modularise and split the applications into interface and the engine code as much as possible. If clever enough you could even define the interface layout using definition files in XML or some other trendy file format :) There's definitely two interfaces here. One that sets up the rules/filters to let certain things happen (John gets this ringtone, Basil shall be ignored) and one that lets those things actually happen. The last interface is dead simple compared to the first. The engine consists of the rules. That engine is terribly complex. I need my agenda, to see I have a meeting, so my phone will not accept calls. However, it needs my phonebook, to see whether one of my colleagues calls me, who *should* be in the meeting, I better take that call after all. agenda and addressbook are available via dbus already. No point in implementing another interface there. Now, depending on circumstances, your Social Other, a parent or child who needs to see a doctor, your bank/mortgage or person that arranges something big for you may need to drag you out of your meeting. Some or most meetings. Probably not all (discussing a raise with your boss, perhaps?) 1) How would you put that in an engine? Where does all the relevant info come from? 2) Then build aan interface to allow an end-user to create such rules. 3) And finally do something trivial with dbus, commandline (or even XML...) to play the appropriate ringtone. and show an Pickup/Cancel pair of buttons. I know that the Home page on Windows Mobile Smartphone edition is just an XML file which can contain links to plugins. That's the easy part, really... Bye, Kero. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
On 18 Jul 2007, at 23:57, Joe Pfeiffer wrote: Note that dbus is already a part of openmoko. Ah, always thought DBUS was some sort of HAL. But on close inspection it's a bit like DCOP which is very powerful. All that's needed is a nice interface to configure the actions then. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
Jim McDonald wrote: [This may have been better to post to the development list but as people are talking about it here I'll start here] Hi, A number of people have been talking about the cool things that they would like their 'phone to do but after spending some time looking at the information available so far I don't see anything that suggests the current codebase will allow people the freedom that they need. If I take a simple example of an incoming call them some of the suggestions that we have seen so far to handle it include different ring tones for different people or groups of people, auto-handling of the call by sending it to voicemail or letting it through, different responses depending on the time of day, /etc. /The point that I'm trying to make is that there are a multitude of things that you /could/ do but each person will have a limited number of things that they want the 'phone to /actually/ do. As such, building out all of these options in to a single piece of code will not only be very hard to manage and maintain but will severely limit the ability of people to scratch their itches and develop code to make the 'phone do what they want it to. If the monolithic approach is out then some sort of modular approach is required. The most obvious example out there today is Firefox, which comes in a relatively simple base configuration but provides any number of hooks to allow people to write their own extensions on top of the base code and as such to alter the functionality of the product very extensively. If we want this openmoko to be as free as possible then it also needs to be as easy as possible for people to extend, and this is the most likely way of doing it. I know that there are a lot of potential problems that need to be addressed when building this out but if there is a vision from the start as to how this would work then it would go a long way to making the final product the 'phone that we are all dreaming of, regardless of the fact that those dreams are often divergent from others if not totally exclusive. So my questions are there plans to include these hooks, and if not can it be considered? Or is there another way to do this other than hooks? Cheers, Jim. Take a look at EToys. http://en.wikipedia.org/wiki/EToys_%28Programming_Language%29 [whoa, that article doesn't even mention OLPC, gotta go edit that] and look at these tiles: http://community.ofset.org/wiki/En-Presentation_of_Squeak_Visuals-Toys Now, imagine a tile that looks like a Neo. It represents the GSM transceiver and modem that lives inside the physical Neo. It has a mike at the bottom and a little speaker at the top. Those are the hooks -- you connect them with little lines to the connectors on other tiles. It has other hooks too, for the other signals that go in and out, like Caller ID and ring signals and such. Of course you have a whole lot of tiles, for sound recorders and sound players and GPS receivers and WiFi and Bluetooth and everything else you can think of. And all that math and program control stuff too. You just program your Neo to do whatever you want it to do by hooking all these tiles together. Now most people wouldn't have a clue how to do such a thing, including a lot of us old fogeys around here, but if the OLPC people get their way millions of children will be learning how to do exactly that Real Soon Now. They will even have the same set of tiles on their little laptops. And in a few years tens of millions of children will be doing it. And then, maybe, hundreds of millions. Pretty much anything they can do in their XOs can also be done in a Neo. And anything they create will work in a Neo too, and it doesn't even have to be ported. EToys runs on Squeak, and Squeak runs bit identically on so many different platforms that it makes my head hurt just thinking about it. So we're gonna have a whole generation of kids who are absolute masters of their little personal Universal Communications Platforms. Doesn't matter if it's an XO or a Neo or whatever, they all work the same, seamlessly. And any task they set their minds to, as long as it fits within the constraints of memory and CPU time and battery life, they will accomplish. Never been so scared in my entire life. Now even if only a tiny fraction of all the wondrous stuff they invent is useful to the rest of us, that will be a whole lot of wondrous stuff. And since it's all open source, you'll just go click on a web page on that little screen and there it's installed. We'll have so many choices it's bound to get confusing for a while. And then Darwinian things happen and the best solutions rise to the top. Nobody can predict what things will look like. Predicting what things will look like is a popular sport around here, and important, but it's not really what OpenMoko is about right now. It's about making something that
Re: Hooks in Base Code
I am not entirely sure if I'm thinking straight, but here's my take on customizing functionality of the OpenMoko: say, when a call comes in, the appropriate module detects that, gets the caller ID if possible, maybe other info (such as the contact info associated with it, if any), and then theres a few things that happen: there could be a config file somewhere that defines a number of 'pre-processing' libraries for the call (or maybe jsut allow one such library), which exports certain functions, such as IncomingCall([some call info here]). Well, OpenMoko would call those functions, and the library(ies) would output some result, such as RejectCall, SendToVoiceMail, PlayAutomaticAnswer, etc. Basically, what I am getting at is that instead of changing the whole OS/kernel to support these functions, it would be possible to write a simple library, and then those libraries would process calls, GPS location changes, etc. Of course, I'm not entirely sure if I'm right so please don't kill me if I'm talking pants. On 7/18/07, Doug Jones [EMAIL PROTECTED] wrote: Jim McDonald wrote: [This may have been better to post to the development list but as people are talking about it here I'll start here] Hi, A number of people have been talking about the cool things that they would like their 'phone to do but after spending some time looking at the information available so far I don't see anything that suggests the current codebase will allow people the freedom that they need. If I take a simple example of an incoming call them some of the suggestions that we have seen so far to handle it include different ring tones for different people or groups of people, auto-handling of the call by sending it to voicemail or letting it through, different responses depending on the time of day, /etc. /The point that I'm trying to make is that there are a multitude of things that you /could/ do but each person will have a limited number of things that they want the 'phone to /actually/ do. As such, building out all of these options in to a single piece of code will not only be very hard to manage and maintain but will severely limit the ability of people to scratch their itches and develop code to make the 'phone do what they want it to. If the monolithic approach is out then some sort of modular approach is required. The most obvious example out there today is Firefox, which comes in a relatively simple base configuration but provides any number of hooks to allow people to write their own extensions on top of the base code and as such to alter the functionality of the product very extensively. If we want this openmoko to be as free as possible then it also needs to be as easy as possible for people to extend, and this is the most likely way of doing it. I know that there are a lot of potential problems that need to be addressed when building this out but if there is a vision from the start as to how this would work then it would go a long way to making the final product the 'phone that we are all dreaming of, regardless of the fact that those dreams are often divergent from others if not totally exclusive. So my questions are there plans to include these hooks, and if not can it be considered? Or is there another way to do this other than hooks? Cheers, Jim. Take a look at EToys. http://en.wikipedia.org/wiki/EToys_%28Programming_Language%29 [whoa, that article doesn't even mention OLPC, gotta go edit that] and look at these tiles: http://community.ofset.org/wiki/En-Presentation_of_Squeak_Visuals-Toys Now, imagine a tile that looks like a Neo. It represents the GSM transceiver and modem that lives inside the physical Neo. It has a mike at the bottom and a little speaker at the top. Those are the hooks -- you connect them with little lines to the connectors on other tiles. It has other hooks too, for the other signals that go in and out, like Caller ID and ring signals and such. Of course you have a whole lot of tiles, for sound recorders and sound players and GPS receivers and WiFi and Bluetooth and everything else you can think of. And all that math and program control stuff too. You just program your Neo to do whatever you want it to do by hooking all these tiles together. Now most people wouldn't have a clue how to do such a thing, including a lot of us old fogeys around here, but if the OLPC people get their way millions of children will be learning how to do exactly that Real Soon Now. They will even have the same set of tiles on their little laptops. And in a few years tens of millions of children will be doing it. And then, maybe, hundreds of millions. Pretty much anything they can do in their XOs can also be done in a Neo. And anything they create will work in a Neo too, and it doesn't even have to be ported. EToys runs on Squeak, and Squeak runs bit identically on so many different platforms that it makes my head hurt just thinking about it.
Re: Hooks in Base Code
Anton Afanasyev wrote: I am not entirely sure if I'm thinking straight, but here's my take on customizing functionality of the OpenMoko: say, when a call comes in, the appropriate module detects that, gets the caller ID if possible, maybe other info (such as the contact info associated with it, if any), and then theres a few things that happen: there could be a config file somewhere that defines a number of 'pre-processing' libraries for the call (or maybe jsut allow one such library), which exports certain functions, such as IncomingCall([some call info here]). Well, OpenMoko would call those functions, and the library(ies) would output some result, such as RejectCall, SendToVoiceMail, PlayAutomaticAnswer, etc. Basically, what I am getting at is that instead of changing the whole OS/kernel to support these functions, it would be possible to write a simple library, and then those libraries would process calls, GPS location changes, etc. Yep that's roughly what I'm talking about but we need the base code to be set up such that it will make those calls and pay attention to the results, which is the main thrust of my argument. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
Doug Jones wrote: Take a look at EToys. [...] That's certainly a style of GUI that could be applied to the hooks if required, although at current I'm more concerned about the ability for the hooks to exist than the specifics of how they would be configured. Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
