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 Ge
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 Ge
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 Ge
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 Ge
Hi,
On Thu, 2014-02-20 at 21:28 +0200, Tomasz Bursztyka wrote:
> 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
Hi Patrik,
Noticed 2 other unnecessary details to remove:
+
+Servicenet.connman
+Interface net.connman.Peer
+Object path[variable prefix]/{peer0,peer1,...}
+
+Methodsvoid Connect()
+
+ Connect this peer.
+
+ Th
Hi Tomaz:
> -Original Message-
> From: connman [mailto:connman-boun...@connman.net] On Behalf Of Tomasz
> Bursztyka
> Sent: Friday, February 21, 2014 6:26
> To: connman@connman.net
> Subject: [PATCH] doc: Add API documentation about WiFi P2P Peer
>
Over all, I do no
Hi,
On Fri, 2014-02-21 at 21:22 +, Xu, Martin wrote:
> Over all, I do not think the API is so perfect for P2P. Since P2P is
> device to device, so device information should be exported, especially
> when we need to support more than one devices at the same time.
We'll do that in d
Hi Martin and Patrik,
As I said in my cover letter: this first part only deals with 1:1 uses
case, which is currently the only real ones in the fields, so no group
at all here.
(and anyway: if there is a layer which should care about the group part,
it's definitely not the application itself.)
Hi
in due time. For the time being the idea was to start out
> small and simple so we get something done.
Good to know. :)
>
> > I know the API is compatible with ConnMan, since ConnMan does not
> > export device information, but I still think BlueZ's P2P API should
> be
> > referenced by us.
>
Hi:
> -Original Message-
> From: connman [mailto:connman-boun...@connman.net] On Behalf Of Tomasz
> Bursztyka
> Sent: Monday, February 24, 2014 1:11
> To: connman@connman.net
> Subject: Re: [PATCH] doc: Add API documentation about WiFi P2P Peer
>
> Hi Martin and P
Hi:
I'd like to speak more on group operation. :)
> However, To me, I also believe that the Group concept in WiFi P2P Spec
> is suck.
>
> Temporary/Persistent group, group loading and all the related stuff is
> really redundant to user.
> The best and simple user experience is
> 1. just to connect
Hi,
Hi:
I'd like to speak more on group operation. :)
However, To me, I also believe that the Group concept in WiFi P2P Spec
is suck.
Temporary/Persistent group, group loading and all the related stuff is
really redundant to user.
The best and simple user experience is
1. just to connect to one
Hi Martin,
Looks like we are on the same line
Indeed, ConnMan will handle necessary group stuff, but won't expose
anything through its own DBus API.
Application don't need to know what's happening about that.
The goal is good, but way to let one peer to load configuration to create the
GO m
Hi,
As far as I know ConnMan use WPA_S without a such file, so I think
ConnMan should be responsible for records and
managing those information, for example, expose a interface to *get*
those persistent group information, and then
a interfaces to*remove* it from ConnMan and WPA_S.
There is
Hi Tomasz,
I think we need to add "[experimental]" status to method call
documentation (especially in manager-api.txt).
The whole peer-api.txt is experimental but in also there it might be
nice to put the experimental string in method descriptions, people might
or will miss the big letter "[EXPER
Am 28.02.2014 15:22, schrieb Tomasz Bursztyka:
> 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()
On 02/28/2014 10:22 PM, Tomasz Bursztyka wrote:
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. R
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 Manag
Hi,
Please forgive me that I maybe not fully catch your points.
I just wander how does ConnMan deal with a incoming p2p connection
request.
I can't find the interface or a signal about notifying user a incoming
request received in your RFC V4.
I did not yet specified that since it requires f
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 p2
Hi Simon,
>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 instan
On 03/03/2014 04:31 PM, Tomasz Bursztyka wrote:
Hi,
Please forgive me that I maybe not fully catch your points.
I just wander how does ConnMan deal with a incoming p2p connection
request.
I can't find the interface or a signal about notifying user a
incoming request received in your RFC V4.
On Fri, 2014-02-28 at 16:22 +0200, Tomasz Bursztyka wrote:
> 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 technolo
24 matches
Mail list logo
