Am 03.03.2014 09:17, schrieb Tomasz Bursztyka: > Hi Simon, > >>> If available, the p2p technology will be instanciated. Note that it's >>> fully dependant over wifi technology: wifi is the parent technology of >>> p2p. >>> >>> If present, it will be possible to run a p2p peers discovery through p2p >>> technology's Scan() method. Results will be provided through Manager API >>> via GetPeers() method and/or PeeersChanged() signal. >> Right now we don't have any way to stop an ongoing scan. How do you want >> to handle the device discovery? Running it forever or just for a limited >> time? > > Second option. This should not be up to the application/management UI to > know when to stop a scan. That said: once implementation will be there, > the time frame will be documented (in an overview document) > so whatever UI client will be able to know when it can re-request a scan > (if it hasn't found a peer yet). This already the case with normal wifi > scan > actually, if a UI always want the refreshed list of wifi services: it > needs to > request a scan again (after first one, and the autoscan delays etc...)
Sounds good to me. Just wanted to clarify this early. >> Furthermore it's also possible to put the device into a listening >> mode. While in listening mode it's possible to be found by other devices >> which can send connection requests. > > Here also we have to be "smart", and hide that to the application: > it should not be up to it to decide here. > Imho, the only proper use case right now is when the device proposes some > services. (if it does not serve anything, why will it want to be > discovered?) > > So, when p2p service part will be specified: if an app add a service, then > ConnMan will handle that and put the device in listening mode. > But that will depend on the p2p service, as I noticed already: we might > enforce being the GO in case of a WiDi/Mirracast sink service for instance. If we want to enforce becoming the GO we still need to say if this means creating an autonomous group and inviting possible clients or just setting an higher intent for the grouper owner negotiation to finally become the GO. But you're right that seems to be really a per service decision. Do you think we should hard code such decisions or make them configurable for the API user? regards, Simon -- Simon Busch - http://mm.gravedo.de/blog/ _______________________________________________ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
