On Sat, Jul 21, 2012 at 08:45:26PM +0200, Simon Busch wrote: > 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?
I'm happy to give you my personal experience. I tried to use the FSO stack back then in 2008 and eventually gave up, for reasons that you seem to want to address. It might be too late, it might not be: mainstream linux distributions aren't really used for making phone calls on mobile phones, except for rare cases, although they do run on mobile phones, so there may be a gap to fill. I gave up trying to integrate GSM-related functions in the software I run in my FreeRunner for several reasons: - the API changed all the time. I would spend 2 days implementing some feature, and it would stop working the following week. - an unstable API based on dbus is insanely frustrating. If I could have had a library-based version of FSO, at least I could see linker errors after, say, you rename a method. Dbus instead just successfully does nothing, because there's nothing on the bus to accept that message. And if (sorry: when) something changed in the chain of asynchronous ping pong that was needed to turn on the GSM chip and go online with my phone provider, things would stop working and it was hard to figure out what would need to be changed. This is in fact where I gave up: at some point I wasn't bothered anymore to start another quest to find out yet again how to turn on the GSM chip. - the whole software stack exploded into shrapnel-like daemons and libraries, and eventually I found myself unable to trace the list of dependencies (and interdependencies) I'd need to satisfy and care about in order to properly my software. And I thought that the learning effort required to catch up wasn't worth it, because my feeling was that there was clearly something insane going on. - I wanted to limit dbus interaction as much as possible, since the FreeRunner couldn't do task switching efficiently. However, I was smelling a trend of solving library issues by introducing yet another higher level daemon that talks dbus with middle level daemons which talk dbus with lower level daemons. I didn't think that 10 task switches for function call were something I wanted to do on a FreeRunner. My needs were rather simple: all I wanted was a tool that would log incoming calls and SMS messages. I would put my Italian SIM into it when I was in the UK, then call people back with my UK SIM which offered cheap calls abroad. The fact that I eventually decided to give up with something that simple, which I had already implemented and which was working, is a good description on how insane FSO had become at some point. Fast forward to now. If your target is allowing, say an EmDebian disto installed on a phone to become a viable platform for developing a usable phone interface, I suggest to pick some basic phone features and ensure that they work in the stack, that they are easy to code with, and that they are easy to deploy. These features are things that I use my N900 for, but that don't work well/at all in my main laptop: - making and receiving one to one calls; - sending and receiving SMS messages; - mobile data connections; - a wake up alarm, which works when the system is suspended. For contact lists, GPS, cameras and so on, there is already software that works. It might not be well integrated with the rest, but it seems to me like they are problems to be solved at a later stage. If in the early days the FreeRunner could have had a stable stack that was only able to keep a mobile data connection open reliably, it would have been a fantastic platform to develop fleet tracking devices. I've never agreed that the main goal of the project should have been competing with the trendy smartphone of the day, and it still shouldn't be today. What I think is needed now are components that give existing distributions capabilities they didn't have before. Then to see what people develop on top of them. But to be appealing to developers who are new to the system (which basically means, all of them), such componends need to be: few, simple, reliable, stable, easy to deploy, and if not documented, at least coming with some working example code. Should I mention they should also be compilable with the *stable* release of the compiler they need? In the past, and for years, I would even have needed to mention that. I want to believe that at least that has already changed :) Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org>
signature.asc
Description: Digital signature
_______________________________________________ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
