Which gsmd will be used in future openmoko?

[Michael 'Mickey' Lauer]

On Tuesday 03 June 2008 12:51:04 Bin Chen wrote:
> On Tue, Jun 3, 2008 at 5:27 PM, Michael 'Mickey' Lauer
>
> <mickey at openmoko.org> wrote:
> > By the way, this would be more suitable on openmoko-devel in my
> > opinion...
> >
> > On Tuesday 03 June 2008 03:35:39 Bin Chen wrote:
> >> As discussed before, seems there is 3 gsmd outstanding...
> >
> > Actually, it's worse. We have 5 options :)
> >
> >> gsmd, gsmd2, ophoned
> >
> > Qtopia, pygsmd
> >
> >> Which one is going to be the default gsm daemon in openmoko?
> >
> > This is hard to tell right now. It depends on how the role / maintenance
> > / importance of the three available image types (Gtk, Qtopia/EFL,
> > Framework/Zhone) evolve over the next couple of months.
> >
> > If we're interested in application developers using telephony without
> > locking them into a language or toolkit, then we rather chose something
> > with a dbus interface. This rules out Qtopia and gsmd. pygsmd is Michael
> > Dietrich's rapid prototyping gsm server for API experiments. This leaves
> > gsmd2 and ophoned -- both sharing most of their API (which is still 
> > evolving, but will stabilize over the next few weeks), so if you start
> > developing against one of these two, you can't be wrong.
> >
> > I personally vote for ophoned, since it's my baby ;)
>
> Thanks.
>
> From the git repos of freesmartphone.org, there is only a ophoned
> written by python, the module name is python-ophoned. So I wonder if
> there is another ophoned written in C or else?

Unclear at this point of time. We're going to focus on the python 
implementation to get to a dbus API as soon as possible, so that people can 
start writing applications on top of that.

Once the python implementation is finished, we're going to profile and check 
whether we actually need to rewrite it in a compiled language. If not, we're 
finished. If so, we'll probably first replace the bottlenecks with compiled 
extension modules. If that still doesn't help, we will consider a 
reimplementation in Vala, C, or C++.

:M: