On Mon, 2016-02-22 at 10:52 +0000, MANIEZZO Marco (MM) wrote:
Thank you for your feedback. Sorry for the email problem, I just
copied/pasted the output of git diff in the mail, for the patch.
Please find the patch in the attached txt.
I agree with you that with 2000 services the d-bus message with this
implementation will be big, our was an implementation more related to
pc / mobile devices where the stored services would be two orders of
magnitude smaller. Moreover the single services GetProperties is
currently deprecated, I wasn't sure to go that direction for
knownServices. We will think about the change accordingly to your
request, maybe in separate phases: first would be to provide only the
path object and second to implement the GetProperties method.
Related to d-bus path names consider that they are used by the Remove
method so I thought that the easiest way was to use the actual file
system path (I mean service_path in var/lib/connman/<service_path>)
plus a postfix; after having stripped the postfix it is easy to remove
the file system data relying on
__connman_storage_remove_service(service->identifier): this is also
2) relevant information already included in the path itself, like
technology, security methods, SSID
Point 2) works only if the service ID is interpreted, by default this
should not be the case (except for giving sane clues for developers, but
that's another story).
3) for application using connman easy matching with nearby services
understand if a stored service is also available for connection
I think there needs to be a service object path property that explicitly
tells what the corresponding service object path is, if any. The other
question from a long time ago was the life cycle of these stored
services, were they going to disappear when they are detected and
created as services or how was the situation supposed to be resolved.
I can change it to have "stored" as a prefix instead of
postfix but I
would keep the <service_path> especially for point 1, but if you have
a different suggestion it is welcome; please let me know your
I'd appreciate that the intended changes were to be documented in ./doc
first so that the API can be discussed and agreed on. Then the
implementation won't be dragged through all discussions and changes.
We'll provide the remove patch separated from knowServices one.