On Fri, 15 Nov 2019 at 15:53, Denis Kenzior <denkenz(a)gmail.com> wrote:
>> I think about this differently. You have 2 phases:
>> 1. Simple Configuration (WiFi Direct flavor) which involves the group
>> formation and wsc negotiation
> Well, it simply isn't part of WSC, but ok.
P2P in the end just took WSC and changed the discovery bits a bit.
Fundamentally its still WSC in the end. But I guess depends on how you
think about it...
>> 2. Actual connection establishment
>> I don't see why Disconnect can't just affect 2 without affecting 1.
>> operations are on different interfaces after all.
> We just don't need 2 methods and I already have Disconnect working
> this way (consistent with Station.Disconnect) so it'd mean just
> artificially crippling it, also adding a race where your Cancel call
> may work or not.
Station.Disconnect does not affect WSC state FYI. It can't since
Station doesn't even know about the ongoing WSC process until after
station_connect_network is invoked. So in that respect we'd be
What I meant is that Disconnect() can cancel your station connection
attempt at any point, while with Peer.Disconnect() you're going to
have to be more careful for no reason.
> (Tecnically provisioning and the connection are both on the P2P_CLIENT
Same as Station/WSC today...
I was just noting they're not happening on different interfaces.