About the future of the freesmartphone.org middleware

2012-07-21 Thread 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

--
Simon Busch - http://mm.gravedo.de/blog/

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: About the future of the freesmartphone.org middleware

2012-07-21 Thread 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@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: About the future of the freesmartphone.org middleware

2012-07-21 Thread Kai L√ľke
Hello,
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,
thanks!
Kai

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@lists.openmoko.org
 http://lists.openmoko.org/mailman/listinfo/community




___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community