About the future of the freesmartphone.org middleware

Thamos tigerred at gmx.de
Sat Jul 21 21:44:01 CEST 2012


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
> 




More information about the community mailing list