About the future of the freesmartphone.org middleware

Kai Lüke kaitobiaslueke at googlemail.com
Sun Jul 22 02:24:29 CEST 2012

I think these all together will be fine. The only thing I have in my
mind beside these is something I ever wanted to try but never did:
redirecting sound (e.g. a sound file with pause melody or answerphone)
to the call input.
But just an idea,

Am 21.07.2012 21:44, schrieb Thamos:
> Hi all.
> I've never seen someone using the conference-feature. I think selecting
> the provider is more important. (this one really annoys me, since i am
> near an border and simply can't phone until i get out auf alien range,
> if the phone switched one time, even reboot doesn't help...). I also
> miss the possibility to choose loudness of the ringtone reasonably. Most
> other phones are even able to choose a ringtone based of the caller!
> Apart from that i comply with you.
> kind regards,
> Thamos
> Am 21.07.2012 20:45, schrieb Simon Busch:
>> Hey everybody,
>> as a lot of you may have noticed we did two releases in the past months
>> of the FSO stack. Both were related to bring stability and consistence
>> to the stack. Now I want to talk with you about the future of the stack.
>> In the past we were only concentrating on getting new hardware supported
>> and lost our real focus on creating a middleware suitable for
>> embedded/specific-purpose devices. This is where I want to go back to
>> and get into development again.
>> In the last weeks I looked over several parts we have in our stack and
>> tried to find out where we can improve and get into development of new
>> features again. A lot of you have stability in mind as you want to use
>> something with FSO on your daily phone. Thats the second peace which
>> should be part of the core development focus of the Freesmartphone.org
>> middleware.
>> Getting new features is fast said but I have several things on my list
>> where I want to improve FSO in the next weeks and months. Everything is
>> focused on the core stack which is formed by our framework libraries and
>> the three daemons fsodeviced, fsogsmd and fsousaged. We have other
>> daemons like fsotdld as well but that will be not on my focus. If
>> someone wants to step up with further development of these just go on
>> and get in contact. But please don't get me wrong: I will support all
>> other daemons like fsoaudiod and fsotdld in the next releases too but
>> just not doing any development related work for them.
>> For fsogsmd there are the following things on my list:
>> 1. Get the last peaces of not implemented things in like conference or
>> emergency calls
>> 2. Several API cleanups
>> 3. Get several bugs fixed
>> 4. Do integration testing with a remote controlled phonesim so we can
>> simulate incoming calls etc. This will also included integration testing
>> with a remote controlled fsogsmd on another device
>> 5. Multi device support: While working in HFP HF support in fsogsmd I
>> discovered that things would be easier if we can control more than one
>> modem with the same daemon at the same time. Think about phone with
>> support for more than one SIM card. Work has already started for this in
>> the morphis/multi-device branch of the cornucopia repository.
>> 6. Cleanup of the modem status handling: right now the modem status and
>> SIM/network status are too much tight together. We have cleanly separate
>> them.
>> 7. Internally we don't separate a modem from a AT based modem; that
>> needs to be fixed
>> 8. A lock-down mechanism to keep anyone out when doing a firmware
>> upgrade. When doing a firmware upgrade of a modem we have the problem
>> that nobody should access the modem while this is in progress. The idea
>> is now to implement a dbus API to lock the modem by requesting a lock
>> and only the requesting program can unlock the modem again. While the
>> modem is locked nobody else can access the modem via fsogsmd.
>> fsousaged:
>> - nothing right now
>> fsodeviced:
>> - nothing right now
>> lib*:
>> - I am thinking about grouping all libraries together so just have one
>> single framework library and don't need to maintain several small
>> libraries which increases the complexity of release testing, ABI
>> refinements, etc. Just one libfsoframework; this is only a thought in my
>> head right and nothing concrete.
>> That are some of my toughs were I want to go with FSO in the next
>> months. So no focus on concrete devices but getting the stack itself
>> forward to be ready for every kind of a device.
>> I would be really happy to hear what other people are thinking about the
>> idea behind FSO since it was started back in 2008. What are your missing
>> features? What do you like and what not?
>> regards,
>> Simon
> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community

More information about the community mailing list