Re: RFC: D-Bus access to all configured services
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
Re: RFC: D-Bus access to all configured services
Hi Slava, 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. Isn't it the same behavior as Jolla's phone has? I still don't get the usefulness of that feature. Why annoying the user with service he cannot connect to, at a time T? (why would he feel the need to tweak the parameters if the network is not even present?!) Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
RFC: D-Bus access to all configured services
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? Regards, -Slava ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: RFC: D-Bus access to all configured services
On 10/07/15 14:51, Marcel Holtmann wrote: 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. Backward compatibility could be provided by having this functionality off by default. And yes, if you turn it on, you would probably have to fix your UI. And I have seen such an UI in Android. A total disaster and I have no intention to put anybody through this. My question was about providing D-Bus access to saved services, not the UI. But since you have touched this topic, forget Android, how would you implement iPhone-style UI with the current D-Bus interface? Anyway, I've got the answer I was looking for. Thanks. -Slava ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: RFC: D-Bus access to all configured services
On 10/07/15 14:56, Tomasz Bursztyka wrote: Hi Slava, 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. Isn't it the same behavior as Jolla's phone has? Not quite. The user gets to see the list of saved networks but their properties are not editable (and not even available in the current UI but that's purely a UI issue). That's why I asked this question. I still don't get the usefulness of that feature. Why annoying the user with service he cannot connect to, at a time T? (why would he feel the need to tweak the parameters if the network is not even present?!) Two scenarios off the top of my head: 1. To see the password (if you have forgotten it) or proxy configuration (to copy/paste it into the new configuration) 2. To set Favourite to false so that it doesn't get automatically connected when it becomes available And generally, if these properties are there and changing them doesn't break anything, why not to provide access to them, especially if there's mechanism already in place for it. connman is a piece of middleware, its job is to provide the functionality and leave it to UI designers to decide what to show, what not to show and how to present it to the user. Regards, -Slava Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: RFC: D-Bus access to all configured services
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. Backward compatibility could be provided by having this functionality off by default. And yes, if you turn it on, you would probably have to fix your UI. I am not a huge fan of adding tons of configuration options. These all need to be tested and they would make the code more complicated. We are providing certain configuration options, because the behavior changes drastically and they all have valid use cases. This one it does not fall into that category. This one should be solved cleanly and be always enabled. So the only way to do this is via a separate method call to retrieve all known services. It is just a lot of people talked about this, but nobody actually implemented it in a clean way. And we never needed this feature in the first place. And I have seen such an UI in Android. A total disaster and I have no intention to put anybody through this. My question was about providing D-Bus access to saved services, not the UI. But since you have touched this topic, forget Android, how would you implement iPhone-style UI with the current D-Bus interface? The UI and the D-Bus API are the same thing. If you read the introduction that I wrote a long time ago, then this has been made pretty clear. UI developers should be able to map this 1:1 to the UI and forget about all the other details since they will be handled for them. iOS style UI is pretty much exactly what gets exposed via services. You would have to go out of your way to create anything more complicated than that. Regards Marcel ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: RFC: D-Bus access to all configured services
Hi Slava, 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. Isn't it the same behavior as Jolla's phone has? Not quite. The user gets to see the list of saved networks but their properties are not editable (and not even available in the current UI but that's purely a UI issue). That's why I asked this question. Ok, could make a bit of sense if the user wants to do some manual cleanups. Though I guess most of users just don't care probably. I still don't get the usefulness of that feature. Why annoying the user with service he cannot connect to, at a time T? (why would he feel the need to tweak the parameters if the network is not even present?!) Two scenarios off the top of my head: 1. To see the password (if you have forgotten it) or proxy configuration (to copy/paste it into the new configuration) 2. To set Favourite to false so that it doesn't get automatically connected when it becomes available And generally, if these properties are there and changing them doesn't break anything, why not to provide access to them, especially if there's mechanism already in place for it. More code to maintain. It's already hard to provide clean and concise API, so providing more functions, opens even more problems: people tend to use the API wrongly :) The more you expose, the more they will mess with. connman is a piece of middleware, its job is to provide the functionality and leave it to UI designers to decide what to show, what not to show and how to present it to the user. That's a debate on its own. Actually, I don't think UI designers should be the only responsible for what to expose on the UI. It then creates a top-to-bottom dependency, without a proper understanding of the lower layers, which tend to generate more problem with time (from maintaining the API to properly architecture the service etc...). Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: RFC: D-Bus access to all configured services
On Fri, 2015-07-10 at 15:45 +0300, Slava Monich wrote: 1. To see the password (if you have forgotten it) or proxy configuration (to copy/paste it into the new configuration) We wasted a few hours thinking on this once upon a time, and concluded that we'll either be close to the AP to verify the passphrase is correct or then we'll have all information a priori 100% correct and are handed a provisioning file. So the end conclusion was that this is not a very valid use case. 2. To set Favourite to false so that it doesn't get automatically connected when it becomes available Technically this is a use case. I have needed something like this when noticing that a network has gone bad and should not be used, but that was after the network was in range and being used. A priori deselecting autoconnect was not found to be a too valid use case either, unfortunately. Cheers, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: RFC: D-Bus access to all configured services
On 10/07/15 16:07, Tomasz Bursztyka wrote: Hi Slava, connman is a piece of middleware, its job is to provide the functionality and leave it to UI designers to decide what to show, what not to show and how to present it to the user. That's a debate on its own. Actually, I don't think UI designers should be the only responsible for what to expose on the UI. It then creates a top-to-bottom dependency, without a proper understanding of the lower layers, which tend to generate more problem with time (from maintaining the API to properly architecture the service etc...). Like many other things, it's a trade-off. Allowing UI designers to blindly produce functional requirements may be a pain from the middleware developer's prospective. On the other hand, letting developers define their own UI would most likely result in something chaotic and visually disturbing like your beloved Android UI (which I'm not actually familiar with but I trust you that it's horrible). Both parties have to talk to each other but someone has to take care of the general consistency across the entire UI platform and it's clearly the job of UI designers. Regarding connman, it's positioned as portable middleware component for Linux-based systems. As such, it can't possibly make any assumptions about the UI. The platform may have no UI at all. Regards, -Slava Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
