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
