About the future of the freesmartphone.org middleware
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
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
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
