Hi Slava, > Does upstream have any interest in providing D-Bus access to all > configured services, including those that have no network associated > with it? Before I start writing any code, I would like to know whether > it's going to be accepted upstream or will remain part of our fork. > > Basically the idea is to add "available" (or whatever you want to call > it) service property which would be true if it's associated with the > network, or false otherwise. Which types of services would provide > access to all services and which only to those that are available, would > be configurable via the conf file. All D-Bus calls (except for "Connect" > obviously) would work for unavailable service just as they do for > available services. > > The main use case is wifi. The user has to be able to see the list of > configured wifi networks, edit their properties, remove them etc. For > other types of services it probably doesn't make sense but who knows. > > I found a relevant 3+ years old discussion in the archives with some > patches, the reaction back then wasn't a definite "no" and yet those > patches were never applied. > > What's the current attitude towards that?
it was a clear no against an "Available" property. That would be the wrong direction to take this. It would also not be backwards compatible and all clients would need to understand what that property means to fix their UI. And I have seen such an UI in Android. A total disaster and I have no intention to put anybody through this. However back then I said, that exposing these services as object path is fine. However the entry point to retrieve them should be something like Manager.GetKnownServices or similar. The important part is really to leave GetServices and its current semantics alone. Regards Marcel _______________________________________________ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
