Hooks in Base Code

Doug Jones dj6mf at frombob.to
Thu Jul 19 02:44:29 CEST 2007

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?

More information about the community mailing list