Which gsmd will be used in future openmoko?

[Bin Chen]

On Tue, Jun 3, 2008 at 7:28 PM, Michael 'Mickey' Lauer
<mickey at openmoko.org> wrote:
> 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++.
>
Thank you very much for your kind help!!

Bin