"Dr. Michael Lauer" <mic...@vanille-media.de> writes: > Hi, > >> Arguably those two paragraphs are already well satisfied by oFono. >> oFono probably now has the advantage in terms of maturity and >> deployment, is compilable by a standard C compiler, and has a recent >> version packaged in Debian. > > FSO is compilable with a standard C compiler as well. Every tarball release > we did has been shipping C files.
Ah sorry, my mistake. (I thought FSO was written in Vala now.) >> The following may sound pointlessly controversial, but I don't intend it >> that way; I think it may help the FSO developers to review and >> understand more precisely their objectives. Why is FSO still needed at >> all, given that oFono exists and appears to have the development >> mindshare and advantages noted above? Would your objectives be achieved >> more quickly or easily by switching to oFono and contributing any needed >> additions to that? > > Oh, FSO is so much more than oFono. If you want to compare, then > compare oFono to fsogsmd alone. I agree that there is a difference in scale, but would draw the opposite conclusion. Probably one of the factors in oFono's success is that it concentrates on doing one thing well. I'm not sure any of the non-GSM FSO components have proved themselves yet. I could be seeing things wrong, but to pull out a couple of examples: - GPS: it seems clear now that it was a mistake to pull that under the FSO umbrella, and that mobile devices should just use standard gpsd instead - the Usage API, which I understand to be motivated mostly by power management, is being rendered unnecessary in many cases by the powering on/off being handled automatically in the kernel. > As for the comparison between those two, well, fsogsmd was first, has (IMO, > of course) > a better architecture, a better API, and supports other modems. And there's no > agenda of a company behind – some people may view that as an advantage, rather > than a disadvantage. > > I don't see why we should invest time in something we consider not being > superior. But might it be less work overall to address those inferiorities in oFono? Regards, Neil _______________________________________________ Openmoko community mailing list firstname.lastname@example.org http://lists.openmoko.org/mailman/listinfo/community