Hooks in Base Code
aasoft at gmail.com
Thu Jul 19 05:13:34 CEST 2007
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 <dj6mf at frombob.to> 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.
> [whoa, that article doesn't even mention OLPC, gotta go edit that]
> and look at these "tiles":
> 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 works so well that ordinary mortals
> will find it attractive, so that millions of them get sold.
> And _after_ those millions of people have OpenMoko phones, some fraction
> of them will gradually discover that the phone can do things that they
> never even thought of using a phone for. The OpenMoko community will be
> there for them, evolving endlessly. What a lovely thought.
> So people who hang around here are putting together stuff that's
> intended to be shipped on a phone. Meanwhile, there's a bunch of people
> on the outskirts who can hardly wait to put _their_ favorite stuff on
> it, and who don't really care what ships on a Neo. But it's all open
> source, so OpenMoko can use anything nice that those other people make,
> and even ship it, even if it hardly uses anything that came out of OpenMoko.
> Look how the OLPC (mostly a python project) has simply included EToys
> (smalltalk). In the same way, OpenMoko can include many different
> environments, all coexisting nicely. All the tools can see all the same
> hooks, whether they call them hooks or not -- everybody has access to
> the same well-documented hardware interfaces.
> So don't worry that the current codebase, or our way of putting it
> together, isn't optimal in various ways. Our task is to figure out how
> to jumpstart that exponential curve. Freedom of communication and
> computation can't really be achieved for anyone until everybody on the
> planet has it, and we need to shift a buttload of hardware to make that
> happen. And I'm getting tired of waiting, see?
> Forget about the flying car. I didn't really want the flying car. I
> always wanted the freedom a lot more than the flying car.
> This IS the future, right?
> OpenMoko community mailing list
> community at lists.openmoko.org
More information about the community