Hi Rémi, On 05.01.2012 13:07, Rémi Denis-Courmont wrote: > Le Mercredi 4 Janvier 2012 18:17:34 ext Daniel Wagner a écrit : >> From: Daniel Wagner <daniel.wag...@bmw-carit.de> >> I think this series is ready to be considered to be merged *hint* :) > > I may be missing something obvious, but why is this a new daemon instead of a > driver or plugin inside oFono?
There are a few reasons why a modem plugin is not really good. Here an summary from my original posting on the ConnMan mailing list: This is the 3rd attempt to get DUN done (pun!). The first and second attempt was to expose DUN devices through the oFono API. While this sounds like a reasonable way to go it has some - let's put it this way - ugliness involved. - No SIM interface: This is not so bad but still we have to hack around this problem. Since we need some uniqueness to distinguish between services, the Serial property of the Modem interface has to be abused for this. - No NetworkRegistration interface: DUN only specifies ATD*99# AT command. All other AT commands might be supported (such as AT+COPS=?) but are not necessarily there. That means we might not get a name for a network. Whereas you can rely to get this name for a regular modem you can't on DUN ones. And guess what you cannot distinguish between real hardware modems and virtual ones unless... - Abuse Modem.Type: ... add 'dun' type and adapt the oFono plugin. That _is_ though a very bad idea. We just introduce a mighty switch for different oFono API behavior. Denis used strong words against this approach. - oFono internal design: oFono is not designed to handle this kind of modems. The dunmodem implementation is rather obscure. The result of this is that, as soon as a DUN device pops up, an Serial channel is opened (rfcomm) and kept alive. Unfortunately, there are phones outside in the wild which like to close the serial link after PPP stops. With oFono's separation of concerns this is not easy to get working. - Technology mess: In order to get DUN modems working you have to enable Cellular and Bluetooth technology. This is really really bad because we expose the implementation details to the user. Sure, DUN is kind of dying etc. but then, I don't think our standards are so low. (http://www.mail-archive.com/connman@connman.net/msg06971.html) cheers, daniel _______________________________________________ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
