Hi Daniel, > >>> we have not yet done this since nobody has come up with a nice API for > >>> handling this. > >> > >> Is the problem really about finding an API approach or is it the actual > >> implementation? > > > > the implementation of course needs some extra work since only available > > services are in memory. None available services are only on disk. > > Is that something that is just caused by the needs of the current > implementation or is the memory footprint a crucial consideration? Would > it be ok to change that and keep all services in memory all the time?
I don't think the memory footprint is an issue. This is just something that has been this way since the beginning. > >> I could imagine giving each service an 'available' flag that signals > >> whether a wifi network is in range. > > > > The list exported by ConnMan is the list of available services. That is > > an implicit property. And we do not want to add a new one. > > A new call you mean? How could users then get to know about 'inactive' ones? > > > For example an Ethernet service only shows up if the cable is plugged in > > and not otherwise. > > > > The UI should be able to take the list as is and display it. No extra > > processing needed. So an availability property is not an option. > > Ok, that's what I thought. > > >> Querying them could either be done using the existing 'ListServices' > >> command, but that would affect the returned result of the an existing > >> implementation, and clients would need to filter for 'available' > >> networks to get the old behaviour back. If changing things that way is > >> no option, we could do the filtering on the server side and add a new > >> call 'ListAllServices' that returns the whole thing. > >> > >> And for removing services, net.connman.Manager could get a call named > >> 'RemoveService' which takes an object path to the service as argument. > >> > >> I can go ahead and have a look on how this could be implemented if it > >> looks like a feasible approach to the maintainers. > > > > Have a look and propose something. It is worth a try. > > The thing is that the two features here are connected. Users (at least > in my case) would most probably delete connections that are not > currently active. So I'd much like to outline the implementation before > I start :) If we look at existing implementation from other operating systems, then we have the following: iOS does exactly what ConnMan does right now which is more accidental than on purpose. MacOS does exactly the opposite and allows you to modify the list of existing/used connection. And if I look at Android I see the list of old connections as well. As I mentioned before, I am not against doing this, but it needs to be intuitive and not clutter the API. For example the Android interfaces are a big disaster in my eyes. People that travel a lot get swamped with endless information. Even MacOS can get pretty nasty. So we need to be smarter here. Regards Marcel _______________________________________________ connman mailing list [email protected] http://lists.connman.net/listinfo/connman
