Hi, Thomas asked me to look at the Connman P2P/Direct APIs to see if we can share some of the interfaces. I think that's a worthwhile goal, so here's a short writeup of where the APIs stand WRT to NetworkManager's current D-Bus API.
doc/wifi-p2p-overview.txt doc/technology-api.txt doc/peer-api.txt The largest issue is that all the interfaces start with "net.connman". If we're going to coordinate on API we should grab some neutral suffix to org.freedeskop.XXXX instead. The second issue is that the APIs have some property-related things that aren't org.fdo.DBus.Properties conformant. I think that's a legacy Connman thing, but eg I don't think we want to support the legacy net.connman.Peer.GetProperties() style functions or signals. Summary (the following from wifi-p2p-overview.txt) ======= WiFi P2P is supported as follows: - if hardware and wpa_supplicant supports it, a "p2p" technology will appear in the technology list * this appears to refer to the Connman Manager object's GetTechnologies() method. It looks like "Technologies" are somewhat like NM's devices, but I'm not sure whether you'll get two Technology objects for two separate wifi interfaces? Patrik? Anyway, one issue is that even if p2p is supported on a specific wifi interface, that interface may have different capabilities that impact how p2p can be used. I don't think we can divorce it entirely from the wifi interface it will be using, which the Connman interfaces appear to do. Might be able to work something out here though (see way below). - "p2p" technology, as for "wifi" technology, supports a Scan() method. Such method will trigger a P2P find process. The results will be available through the Manager interface, comparable to services being available through this same interface after a Scan() on "wifi" technology. * Scan() for p2p discovery sounds fine to me, but we'll have to figure out whether this should be on the WiFi device itself, or whether a global method is OK. I can see arguments both ways, but I guess most client apps using P2P won't care about wifi at all really, just about P2P. - the result of a "p2p" Scan() consists into a list of "peer" objects * This we might be able to implement. It looks like these are top-level objects in Connman instead, with no relation to their parent WiFi interface through which they will be reached. But like I said above, perhaps most clients using P2P don't actually care how the peer is found? and thus just care about P2P and not the parent wifi interface. - it is then possible to access peer information, connecting and disconnecting it via the Peer API. * As above, the Peer API might be something we can mostly use as-is if we can get a namespace change. API Usage (also from wifi-p2p-overview.txt) ========= The UI willing to access to WiFi P2P technology should proceed this way: - Request Manager.GetTechnologies() and figure out from the result if "p2p" technology is provided. What comes next implies this successful case. * I'd rather have a separate org.fdo.XXX.WiFiP2P interface on the top-level object that has a Capabilities properties with flags like "none", "client", "group owner". That would be more generic and then NM wouldn't have to deal with technologies. This interface would also have the Scan() method to find peers. - Add a listener to signal Manager.PeersChanged(): this signal will provide the results of a "p2p" technology Scan(). * I'd rather have this be signal on org.fdo.XXX.WiFiP2P instead, and coupled with an "ao" type Peers property that is an array of object paths to peers. There would also be PropertiesChanged signals for Peers. - From the "p2p" technology object, request a Technology.Scan() method. This will run for a while a P2P find process. * I'd rather have this on org.fdo.XXX.WiFiP2P, and it would emit changes to the Peers property as above. - If P2P peers are found, it will be signaled through Manager.PeersChanged(). Objects are "Peer" objects. UI might use Manager.GetPeers() instead, if listening to a signal is not the preferred way. * as above, I'd rather have a different dbus interface for these. - Once selected the proper Peer object, request a Peer.Connect() method on it so it will connect to it. Peer.Disconnect() will disconnect. * this should be mostly fine. ----------- The biggest question in my mind is whether the P2P operations can be (or should be) completely divorced from the WiFi interface they will be using. Do clients care about the WiFi interface? Quite possibly they don't; imagine a scenario in which you connect to a camera with P2P, where the Photos app doesn't care about wifi, it just wants to find some remote cameras it can connect to. I think there are restrictions in the drivers sometimes with whether they can be a Group Owner or client at the same time as a WiFi STA though, so clearly there would have to arbitration in some cases to warn the user they'd have to disconnect from their AP to do some of the P2P stuff. ----------- Assuming clients don't care about the parent WiFi interface at all, I could see this interface being usable: org.freedesktop.XXXX.WiFiP2P - Scan(): starts a scan for new peers on all capable WiFi devices - Peers: ao: array of object paths of Peer objects - GetPeers()->ao: returns same results as Peers property - PeersChanged(a(oa{sv}), ao): signal containing new peers and their properties, and removed peers - standard D-Bus Properties API signals/methods too - RegisterPeerService(a{sv}, bool) - registers local P2P service - UnregisterPeerService(a{sv}) - unregisters local P2P service org.freedesktop.XXXX.WiFiP2P.Peer - Connect() - Disconnect() - State - Name - IPv4 - ? How about IPv6? - Services Patrik, any comments? Dan _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list