Hi Daniel, > > > > - why config is in XML and why does it duplicates some data that is > > > > stored in connman and ofono? I'd rather use simple pickle if it is > > > > meant to be always in Python, or ini-like format as allowed by the > > > > ConfigFile python module, it would be more in sync with connman :-) > > > > > > It is not really import in what format the configuration is. The choice > > > to for XML was based on the fact that managers like XML. They understand > > > what XML is. That's all. Could be anything else. > > > > > > A good question is what kind of information is stored in this file. The > > > aim is that you can preconfigure your connection manager (provisioning) > > > so that the user (driver) doesn't have to do anything. > > > > actually ConnMan supports that already. Look at doc/config-format.txt. > > You just drop one of these in /var/lib/connman/ and it will provision > > services for you. These services even become immutable and thus > > protected from end user interference. > > Fair enough, the profiles store the passwords for a given > services. This part in my config file should be stored in connman's > profiles.
the profiles are different from config file. The config file is the provision information. Including things like auto-connect and priority and things like that. There is a difference between provision data and configuration that comes from a user. Hence the Immutable property. > For consistency sake, I'd like to see the PINs for the SIMs stored at > the same place. If ofono would have the same kind of service > configuration storage that would be nice. I'll have to look this up :) My take on SIM PINs is that they are pointless. If you don't wanna enter a PIN for your SIM card, then disable it. Storing them on the filesystem is as good as disabling them. Especially for integrated SIM cards that for come with a system and are not removable anyway. > What about additional configuration? There are two more things in the > config file. The application priority mapping and the technology > priority mapping. I think those two things are nothing for connman. They should be to some degree. A config file could provide a sensible default and then users can change these. If there are multiple choices then there are use cases where it might make sense. > Soon I'd like to add some sort of accounting configuration. For > example, if a user overcommits his 'flatline' then the connection is > terminated. Maybe this is something which is generic enough to get it > into connman. What do you think? We have a start for this with the counter API. It needs some extra work of course to have this all figured out. There are many use cases that will not work right away and need extra development. So any help is welcome here. An obvious thing right now is that accounting details are not stored persistent on the filesystem. Regards Marcel _______________________________________________ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
