Connman WiFi p2p API evaluation

[Dan Williams <dcbw redhat com>]

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