"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
_______________________________________________
Shr-devel mailing list
Shr-devel@lists.shr-project.org
http://lists.shr-project.org/mailman/listinfo/shr-devel
