Hi Daniel,
> >> two quick questions:
> >>
> >> * is there a way to get a list of services that have once been
> >> configured but are not currently available anymore? (IOW, list
> >> everything in ${localstatedir}/lib/connman/)
> >>
> >> * is there a way to remove a configured connection, also one that is not
> >> necessarily currently available? Background is that I want to offer a
> >> way to prevent connman from automatically connecting to wacky Wifi
> >> services (ie, remove an entry from ${localstatedir}/lib/connman/)
> >>
> >> I couldn't find appropriate calls from digging thru the DBus
> >> introspections.
> >
> > 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.
> 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.
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.
> 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.
Regards
Marcel
_______________________________________________
connman mailing list
[email protected]
http://lists.connman.net/listinfo/connman
