[PATCH 0/5] [RFC] implement 'unavailable' services and service removal

Daniel Mack zonque at gmail.com
Mon Jan 2 04:27:34 PST 2012


Hi Marcel,

On 12/22/2011 06:02 PM, Marcel Holtmann wrote:
>> GetServices would return the available services and GetSavedServices 
>> would return the stored services. The available and stored services 
>> would a combination of these two lists.
> 
> The only real problem is that the UI now would have to deal with
> duplicates. I wanna avoid that.
> 
> So essentially you have two lists. One is "all services in range" and
> the other "known services not in range".
> 
> The combination of this list and all of them marked as Favorite are the
> ones you can Remove.
> 
> The real fun begins when a service moves from one list to the other one.
> Since essentially we have to have signals for that. There could be more
> than one application showing the not in range, but known services. So if
> one applications calls Remove the list actually does change.

Which is why my idea was to have them in one list, and flag them
accordingly.

> The Favorite flag distinguishes between a service in range that we
> already know and a service in range that we do not know.

Which is what the "saved" flag would also do, as a "favorite" service is
also always "stored". Maybe we can start off by renaming the flag?

> You do wanna know if a Remove call would succeed or not. Since if not
> the UI can just hide that button. 

All information whether or not it would succeed is denoted in the flags
a service provides, right?

> If you confuse the user with a Remove
> button that just produces an error or does nothing; bad idea.

Agreed.

>> - the Remove dbus API could be used to remove a saved service like in 
>> your patch (it would use the object patch returned by GetSavedServices)
>>
>> The GetSavedServices would be used by UI or is there some other use 
>> cases for that API?
> 
> Maybe it is just easier to separate both code paths and document exactly
> what user is suppose to use which.

Yes, but to combine both flexibility and compatability, I still think
having one big list with services inside is a feasible way to go. Not to
break existing application, the calls that are there already should
maintain its behaviour for sure, but I think a new call that passed back
an unfiltered version of what's there already is something that can be
sold to users.

> We could have a GetKnownServices() method with its signals attached to
> it. And that is supposed to be used by the configuration application if
> you care. And the GetServices is actually for just selection of your
> network.
> 
> If a user connects to a new network it would be result in a signal
> KnownServiceAdded (assuming we do not care about the order).

Well, to me that sounds like quite some overhead in both the client and
the server. Wouldn't it be easier to track services in the client and
make the service emit a signal, so that users can attach to it if they
really want to have this kind of information?

> Applications trying to combine these two lists will be in an awful lot
> of pain doing so. They could do it, but it would create big overhead and
> that is maybe a good thing. Since presenting information to the user
> that he/she doesn't care about should be as hard as it gets ;)

Yes, but which way would you suggest then? :)


Daniel


More information about the connman mailing list