Re: [RFCv3] Document P2P dbus interfaces

[Denis Kenzior <denkenz@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1480 bytes --]

Hi Andrew,

>>   And if we become a GO, then things
>> become even more funny since we can only send invites, not actually
>> initiate a connection.
> 
> Invitation is just a technical name for a frame sequence, group
> formation is another, but it's just ways to connect to a device.  Note
> how Android shows the same Accept/Decline dialog whether you're using
> group formation or invitation. (same or similar... I thought the
> wording was the same but don't have screenshots at hand)

- How are you handling the case where the Peer wants us to display our 
PIN?  And provision discovery in general?
- Invitations?
- invitation by a P2P Device (not group owner) of another P2P Device?
- The fact that GO has a bunch of stats about its clients and you 
probably want to expose that similarly to AP mode?
- The fact that GO has to handle connections from legacy clients and 
thus needs to provide legacy WPS methods?
- persistent groups, with custom or saved credentials?

To me it seems quite impractical to mix GO and client and to try and 
hide these details.  I have very strong doubts you will succeed here.

And I also think you're not avoiding exposing topology details.  For 
example, is Peer.Disconnect resulting in a disconnection of a single 
peer or group tear down?

I think you really need to send a v4.  I just don't see how you're 
handling many of the P2P concepts, much less P2P-GO specific ones in 
this one.

Regards,
-Denis