Re: [PATCH] doc: Add API documentation about WiFi P2P Peer
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 technology's Scan() method. Results will be provided through Manager API via GetPeers() method and/or PeeersChanged() signal. Let's start off in this direction. Applied, thanks! Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] doc: Add API documentation about WiFi P2P Peer
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 finding out how we could do this properly. Here probably how it will work: - our device serves a p2p service, thus is discoverable - a device tries to pair with us - Agent API will provide a method to run the WPS PBC/PIN here, if we cancel the call: it means we reject the pairing. - in case of WPS PBC or PIN done, then the proper logic is ran. Up to the other device to handle it also. I did not yet specified anything, since we are currently focusing on client that: on that particular case, current Agent API is fully functional. Br, Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] doc: Add API documentation about WiFi P2P Peer
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 p2p technology's Scan() method. Results will be provided through Manager API via GetPeers() method and/or PeeersChanged() signal. Right now we don't have any way to stop an ongoing scan. How do you want to handle the device discovery? Running it forever or just for a limited time? Second option. This should not be up to the application/management UI to know when to stop a scan. That said: once implementation will be there, the time frame will be documented (in an overview document) so whatever UI client will be able to know when it can re-request a scan (if it hasn't found a peer yet). This already the case with normal wifi scan actually, if a UI always want the refreshed list of wifi services: it needs to request a scan again (after first one, and the autoscan delays etc...) Sounds good to me. Just wanted to clarify this early. Furthermore it's also possible to put the device into a listening mode. While in listening mode it's possible to be found by other devices which can send connection requests. Here also we have to be smart, and hide that to the application: it should not be up to it to decide here. Imho, the only proper use case right now is when the device proposes some services. (if it does not serve anything, why will it want to be discovered?) 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 instance. If we want to enforce becoming the GO we still need to say if this means creating an autonomous group and inviting possible clients or just setting an higher intent for the grouper owner negotiation to finally become the GO. But you're right that seems to be really a per service decision. Do you think we should hard code such decisions or make them configurable for the API user? regards, Simon -- Simon Busch - http://mm.gravedo.de/blog/ ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] doc: Add API documentation about WiFi P2P Peer
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 instance. If we want to enforce becoming the GO we still need to say if this means creating an autonomous group and inviting possible clients or just setting an higher intent for the grouper owner negotiation to finally become the GO. But you're right that seems to be really a per service decision. Do you think we should hard code such decisions or make them configurable for the API user? We should try to hard code as many decisions as possible, applications should really not care about p2p low level details. I think we can decide when to create an autonomous persistent GO depending on service being proposed. Currently I only have widi/mirracast sink role in mind but there might be other. On other use case, we can cut the pear in half: 6-7 as a GO intent and happens what happens. I don't know yet: let's see what will come out of implementation and practical testing. In any case we should let this decision to any app/ui: it's too low level. If it happens we end up as the GO for whatever reason, when UI will request a Connect() on a Peer, it will use invite() behind, etc... That will be figured out exactly during implementation. That's why I did not put anything related to groups anywhere in the API. And it might be we will not have to at any moment.I am confident we can cut a lot of nasty details out of applications, and handle those smoothly behind the curtains. Br, Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] doc: Add API documentation about WiFi P2P Peer
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. I did not yet specified that since it requires finding out how we could do this properly. Here probably how it will work: - our device serves a p2p service, thus is discoverable - a device tries to pair with us - Agent API will provide a method to run the WPS PBC/PIN here, if we cancel the call: it means we reject the pairing. - in case of WPS PBC or PIN done, then the proper logic is ran. Up to the other device to handle it also. I did not yet specified anything, since we are currently focusing on client that: on that particular case, current Agent API is fully functional. All right, Thanks for your answer! Best Regards Guoqiang ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] doc: Add API documentation about WiFi P2P Peer
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. Results will be provided through Manager API via GetPeers() method and/or PeeersChanged() signal. --- doc/manager-api.txt| 29 + doc/peer-api.txt | 49 + doc/technology-api.txt | 4 3 files changed, 82 insertions(+) create mode 100644 doc/peer-api.txt Hi Tomasz, 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. Is it not category on this version? I think this logic is atomic even a mini p2p stack. Best Regards Guoqiang ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] doc: Add API documentation about WiFi P2P Peer
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 [EXPERIMENTAL] in the beginning of the
file anyway.
Cheers,
Jukka
On pe, 2014-02-28 at 15:09 +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
technology's Scan() method. Results will be provided through Manager API
via GetPeers() method and/or PeeersChanged() signal.
---
doc/manager-api.txt| 29 +
doc/peer-api.txt | 49 +
doc/technology-api.txt | 4
3 files changed, 82 insertions(+)
create mode 100644 doc/peer-api.txt
diff --git a/doc/manager-api.txt b/doc/manager-api.txt
index 8f1333c..445dd92 100644
--- a/doc/manager-api.txt
+++ b/doc/manager-api.txt
@@ -39,6 +39,13 @@ Methodsdict GetProperties()
Possible Errors: [service].Error.InvalidArguments
+ array{object,dict} GetPeers()
+
+ Returns a sorted list of tuples with peer object path
+ and dictionary of peer properties
+
+ Possible Errors: [peer].Error.InvalidArguments
+
object ConnectProvider(dict provider) [deprecated]
Connect to a VPN specified by the given provider
@@ -186,6 +193,28 @@ Signals TechnologyAdded(object path, dict
properties)
required to watch the PropertyChanged signal of
the service object.
+ PeersChanged(array{object, dict})
+
+ Signals a list of peers that have been changed via the
+ first array. And a list of peer that have been removed
+ via the second array.
+
+ The list of changed peers is sorted. The dictionary
+ with the properties might be empty in case none of the
+ properties have changed. Or only contains the
+ properties that have changed.
+
+ For newly added peers the whole set of properties will
+ be present.
+
+ The list of removed peers can be empty.
+
+ This signal will only be triggered when the sort order
+ of the peer list or the number of peers changes. It
+ will not be emitted if only a property of the peer
+ object changes. For that it is required to watch the
+ PropertyChanged signal of the peer object.
+
PropertyChanged(string name, variant value)
This signal indicates a changed value of the given
diff --git a/doc/peer-api.txt b/doc/peer-api.txt
new file mode 100644
index 000..659045d
--- /dev/null
+++ b/doc/peer-api.txt
@@ -0,0 +1,49 @@
+Peer hierarchy [EXPERIMENTAL]
+=
+
+Service net.connman
+Interfacenet.connman.Peer
+Object path [variable prefix]/{peer0,peer1,...}
+
+Methods void Connect()
+
+ Connect this peer.
+
+ This method call will only return in case of an error
+ or when the peer is fully connected. So setting a
+ longer D-Bus timeout might be a really good idea.
+
+ Possible Errors: [service].Error.InvalidArguments
+
+ void Disconnect()
+
+ Disconnect this peer. If the peer is not connected, an
+ error message will be generated.
+
+ Possible Errors: [service].Error.InvalidArguments
+
+Signals PropertyChanged(string name, variant value)
+
+ This signal indicates a changed value of the given
+ property.
+
+Properties string State [readonly]
+
+ The peer state information.
+
+ Valid state are idle, failure, association,
+ configuration, ready and disconnect.
+
+ string Name [readonly]
+
+ Name of the peer.
+
+ dict IPv4 [readonly]
+
+ string Address [readonly]
+
+ The current configured IPv4 address.
+
+ string Netmask [readonly]
+
+ The current configured IPv4 netmask.
diff --git a/doc/technology-api.txt b/doc/technology-api.txt
index 2da08de..77a0f02 100644
---
RE: [PATCH] doc: Add API documentation about WiFi P2P Peer
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. Good point. In due time, yes. What does parent technology mean here? A 'p2p' technology, similar to 'wifi', 'ethernet' etc. What good would a group owner API do? At Group owner is a side effect of P2P, it's not something service providing applications want to mess around with. Apps basically want to know an interface and/or IPv4 address to bind to and be happy. Much like the situation is for any other normal interface/IP combo. You mean you do not want to add group API and do not want to export Group stuff? If so, that's great. I just think from WiFi P2P Spec before. 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 peer 2. and the connection configuration/credential can be recorded(so called persistent group) 3. next time can be reconnect without the process of WPS and Go-negotiation process Thanks! :) ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
RE: [PATCH] doc: Add API documentation about WiFi P2P Peer
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 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.) As I reply to Partik's mail. If we can totally hide the group concept to user That is great. For normal user, group is redundant. They just need to scan The peer, and then connect, and next time can reconnect. That's all. I prefer to be conservative now, and exposing the less possible. It's far better to add useful things later, than scrapping useless ones afterwards since people would have already started to use the API etc... That's the right approach. :) 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. Good point. In due time, yes. It's actually already following that path: p2p technology's Scan() is like a Discovery() I just did not wanted to add this specific name, when Scan() exists already and when semantically it is very close: a scan discovers other entities. And peer object are like device object. It just makes more sense to call it peer... as in peer-to-peer. I just prefer to use device as the local peer, and peer as the remote peer. We will find that local peer and remote peer has different method and properties. And some of the methods like scan can move to device. Anyway for now, first step, it is good enough. :) Rest will have to be evaluated like: some kind of profiles, etc... + Valid state are idle, failure, association, + configuration, ready and disconnect. association and configuration is useful? This follows the service states, which is a plus. I'm not sure we'll need all this state information, let's see. Yep, I put all states as for services (minus online since obviously we are not supposed to get it). I agree: whatever possible superfluous states should be removed, if necessary. No renaming though. Yes, service states is not suitable with P2P. We might stick with the primary value. (Actually, a proper UI should show an icon related to this type, but that's not our part) Agree, UI should need to show some icon according our type string. I am still questioning myself about exposing discovered peers MAC address. In many P2P usage I have seen people caring more about it than the peer's name (aka: device name) Which is very stupid: a MAC is way less human readable than a proper name but anyway... Name can be changed at any time, but MAC never got changed. :) ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
RE: [PATCH] doc: Add API documentation about WiFi P2P Peer
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 peer 2. and the connection configuration/credential can be recorded(so called persistent group) 3. next time can be reconnect without the process of WPS and Go-negotiation process So as to group operation, I think what WiFi P2P spec want to do is just 1. One peer Load so called persistent group, and work as the GO and wait other peer to connect 2. the other peer can connect the created GO with original credential. The goal is good, but way to let one peer to load configuration to create the GO manually is really stupid. That should be done automatically and transparently to user. I think the connection configuration(SSID, GO, Credential, so called persistent group) should always be recorded. So next time, one peer send connection requests, and found that they ever be connected(Through MAC address), just load the configuration automatically. And never need user involve. I think we can do that at WPA_S. ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] doc: Add API documentation about WiFi P2P Peer
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 peer
2. and the connection configuration/credential can be recorded(so
called persistent group) 3. next time can be reconnect without the
process of WPS and Go-negotiation process
So as to group operation, I think what WiFi P2P spec want to do is just
1. One peer Load so called persistent group, and work as the GO and wait other
peer to connect
2. the other peer can connect the created GO with original credential.
The goal is good, but way to let one peer to load configuration to create the
GO manually is really stupid.
That should be done automatically and transparently to user.
I think the connection configuration(SSID, GO, Credential, so called persistent
group) should always be recorded.
So next time, one peer send connection requests, and found that they ever be
connected(Through MAC address), just load the configuration automatically.
And never need user involve. I think we can do that at WPA_S.
Yes, WPA_S just did it as you said.
I think it is a good point that the group operation is transparently to
users when a group founded.
if WPA_S use a configure file, it will record the persistent group
information like this in the file:
network={
ssid=DIRECT-BU
bssid=02:90:4c:02:3b:9f
psk=cZpEMHRO
proto=RSN
key_mgmt=WPA-PSK
pairwise=CCMP
auth_alg=OPEN
mode=3
disabled=2
p2p_client_list=da:50:e6:03:86:20
}
When WPA_S start up, it will load it automatically to get ready for
re-invoking a persistent group.
we also can use wpa_cli list_networks to find that, and use
remove_network to remove it.
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.
HTH
Guoqiang
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] doc: Add API documentation about WiFi P2P Peer
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 manually is really stupid. That should be done automatically and transparently to user. Yep we should not let the application touching these. However, in very specific cases, ConnMan might need to create the GO by itself (rather than asking for negotiating it). For instance if you serve a display as a sink, you just want to be sure everything gets routed to you by default. Of course, transparently as usual so applications won't notice anything. Btw, I have started to work on service discovery/addition/deletion, it should come soon in the test script I did. That will help us finding out how to expose services and methods related to those. So handling this specific case will come when we will have decided what to expose about P2P services. I think the connection configuration(SSID, GO, Credential, so called persistent group) should always be recorded. So next time, one peer send connection requests, and found that they ever be connected(Through MAC address), just load the configuration automatically. And never need user involve. I think we can do that at WPA_S. Exactly what I had in mind. As long as we detect the group we are part of as persistent one: we store the data (as we do for services etc...) and handling a reconnection to it will be transparent. Br, Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] doc: Add API documentation about WiFi P2P Peer
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 no need to expose anything. Afaik, wpa_s exposes already useful information and methods for that through DBus API. It might be buggy though, we will see. Br, Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] doc: Add API documentation about WiFi P2P Peer
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.) I prefer to be conservative now, and exposing the less possible. It's far better to add useful things later, than scrapping useless ones afterwards since people would have already started to use the API etc... 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. Good point. In due time, yes. It's actually already following that path: p2p technology's Scan() is like a Discovery() I just did not wanted to add this specific name, when Scan() exists already and when semantically it is very close: a scan discovers other entities. And peer object are like device object. It just makes more sense to call it peer... as in peer-to-peer. Rest will have to be evaluated like: some kind of profiles, etc... + Valid state are idle, failure, association, + configuration, ready and disconnect. association and configuration is useful? This follows the service states, which is a plus. I'm not sure we'll need all this state information, let's see. Yep, I put all states as for services (minus online since obviously we are not supposed to get it). I agree: whatever possible superfluous states should be removed, if necessary. No renaming though. + string Name [readonly] + + Name of the peer. We also need type, UI needs to show the device type. When we manage to read through the spec up to this point, it will be added. If we have to export it, it should be through a proper string and nothing else. We might stick with the primary value. (Actually, a proper UI should show an icon related to this type, but that's not our part) And still, a proper peer name should be sufficient here, so let's wait for that. I am not keen on integrating it just yet. Do we really need to export the peer IPV4 to user? I think for Peer, MAC address is more useful This would be our local IPv4 address. I think applications would like to know that. I am still questioning myself about exposing discovered peers MAC address. In many P2P usage I have seen people caring more about it than the peer's name (aka: device name) Which is very stupid: a MAC is way less human readable than a proper name but anyway... Br, Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] doc: Add API documentation about WiFi P2P Peer
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 due time. For the time being the idea was to start out small and simple so we get something done. 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. Good point. In due time, yes. What does parent technology mean here? A 'p2p' technology, similar to 'wifi', 'ethernet' etc. +Methodsvoid Connect() Can we handle it Asynchronously and just use the state signal to notify user? I don't think so. It shall work the same as in all the other APIs. We also need to a parameter to set persistent group or temporary group. No. There is nothing useful the application can do by knowing the group type. ConnMan takes care of this details (actually it should be wpa_supplicant, but we all know we can't have that). + Valid state are idle, failure, association, + configuration, ready and disconnect. association and configuration is useful? This follows the service states, which is a plus. I'm not sure we'll need all this state information, let's see. + string Name [readonly] + + Name of the peer. We also need type, UI needs to show the device type. When we manage to read through the spec up to this point, it will be added. And if the peer is group owner, In fact It will join the group, so group information is also Need. And of what use would such information be to the calling application? None? The group owner stuff is ConnMan's problem (actually it should be again wpa_supplicant, but...). Perhaps - but only perhaps - a group name is useful. Let's see. Do we really need to export the peer IPV4 to user? I think for Peer, MAC address is more useful This would be our local IPv4 address. I think applications would like to know that. Could you also give out group API at same time?. Group operation is the key operation in WiFi P2P, it is difficult for us to discuss WiFi P2P without group. What good would a group owner API do? At Group owner is a side effect of P2P, it's not something service providing applications want to mess around with. Apps basically want to know an interface and/or IPv4 address to bind to and be happy. Much like the situation is for any other normal interface/IP combo. HTH, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] doc: Add API documentation about WiFi P2P Peer
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 p2p
technology's Scan() method. Results will be provided through Manager API
via GetPeers() method and/or PeeersChanged() signal.
---
doc/manager-api.txt| 29
doc/peer-api.txt | 60
++
doc/technology-api.txt | 5 +
3 files changed, 94 insertions(+)
create mode 100644 doc/peer-api.txt
diff --git a/doc/manager-api.txt b/doc/manager-api.txt
index 8f1333c..445dd92 100644
--- a/doc/manager-api.txt
+++ b/doc/manager-api.txt
@@ -39,6 +39,13 @@ Methodsdict GetProperties()
Possible Errors: [service].Error.InvalidArguments
+ array{object,dict} GetPeers()
+
+ Returns a sorted list of tuples with peer object path
+ and dictionary of peer properties
+
+ Possible Errors: [peer].Error.InvalidArguments
+
object ConnectProvider(dict provider) [deprecated]
Connect to a VPN specified by the given provider
@@ -186,6 +193,28 @@ Signals TechnologyAdded(object path, dict
properties)
required to watch the PropertyChanged signal of
the service object.
+ PeersChanged(array{object, dict})
+
+ Signals a list of peers that have been changed via the
+ first array. And a list of peer that have been removed
+ via the second array.
+
+ The list of changed peers is sorted. The dictionary
+ with the properties might be empty in case none of the
+ properties have changed. Or only contains the
+ properties that have changed.
+
+ For newly added peers the whole set of properties will
+ be present.
+
+ The list of removed peers can be empty.
+
+ This signal will only be triggered when the sort order
+ of the peer list or the number of peers changes. It
+ will not be emitted if only a property of the peer
+ object changes. For that it is required to watch the
+ PropertyChanged signal of the peer object.
+
PropertyChanged(string name, variant value)
This signal indicates a changed value of the given
diff --git a/doc/peer-api.txt b/doc/peer-api.txt
new file mode 100644
index 000..c56ba8f
--- /dev/null
+++ b/doc/peer-api.txt
@@ -0,0 +1,60 @@
+Peer hierarchy [EXPERIMENTAL]
+=
+
+Service net.connman
+Interfacenet.connman.Peer
+Object path [variable prefix]/{peer0,peer1,...}
+
+Methods void Connect()
+
+ Connect this peer.
+
+ This method call will only return in case of an error
+ or when the peer is fully connected. So setting a
+ longer D-Bus timeout might be a really good idea.
+
+ If we are already part of a group as the group owner,
+ it will invite this peer.
+
+ Possible Errors: [service].Errori.InvalidArguments
+
+ void Disconnect()
+
+ Disconnect this peer. If the peer is not connected, an
+ error message will be generated.
+
+ If we are already part of a group as the group owner,
+ it will reject this peer.
+
+ Possible Errors: [service].Error.InvalidArguments
+
+Signals PropertyChanged(string name, variant value)
+
+ This signal indicates a changed value of the given
+ property.
+
+Properties string State [readonly]
+
+ The peer state information.
+
+ Valid state are idle, failure, association,
+ configuration, ready and disconnect.
+
+ string Name [readonly]
+
+ Name of the peer.
+
+ string GroupName [readonly]
+
+ Name of the group this peer belongs, as a group owner
+ or not.
+
As discussed offline, maybe we'll add a GroupName property only when
there is a code handling it and a proper need to expose it. Maybe the
end result is not to post the group name at all...
+ dict IPv4 [readonly]
+
+ string Address [readonly]
+
+ The
Re: [PATCH] doc: Add API documentation about WiFi P2P Peer
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.
+
+ This method call will only return in case of an error
+ or when the peer is fully connected. So setting a
+ longer D-Bus timeout might be a really good idea.
+
+ If we are already part of a group as the group owner,
+ it will invite this peer.
This detail on what's going to happen behind (about being a GO) is also
superfluous
+
+ void Disconnect()
+
+ Disconnect this peer. If the peer is not connected, an
+ error message will be generated.
+
+ If we are already part of a group as the group owner,
+ it will reject this peer.
Same here.
I'll prepare a second version
Tomasz
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
RE: [PATCH] doc: Add API documentation about WiFi P2P Peer
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 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.
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.
But for the initial implementation, I am ok to use your API style, and not
waste too much time argue API here, and just make initial implementation work.
:)
Below is my comments.
If available, the p2p technology will be instanciated. Note that it's
fully dependant over wifi technology: wifi is the parent technology of
p2p.
What does parent technology mean here?
And how to define wifi technology here? it is WiFi station, WiFi AP or general
WiFi?
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 GetPeers() method and/or PeeersChanged() signal.
---
doc/manager-api.txt| 29 +
doc/peer-api.txt | 49
+
doc/technology-api.txt | 4
3 files changed, 82 insertions(+)
+Object path [variable prefix]/{peer0,peer1,...}
+
+Methods void Connect()
+
+ Connect this peer.
+
+ This method call will only return in case of an error
+ or when the peer is fully connected. So setting a
+ longer D-Bus timeout might be a really good idea.
+
+ Possible Errors: [service].Errori.InvalidArguments
Can we handle it Asynchronously and just use the state signal to notify user?
We also need to a parameter to set persistent group or temporary group.
+ void Disconnect()
+
+ Disconnect this peer. If the peer is not connected,
an
+ error message will be generated.
+
+ Possible Errors: [service].Error.InvalidArguments
+
+Signals PropertyChanged(string name, variant value)
+
+ This signal indicates a changed value of the given
+ property.
+
+Properties string State [readonly]
+
+ The peer state information.
+
+ Valid state are idle, failure, association,
+ configuration, ready and disconnect.
association and configuration is useful? I prefer connecting.
ready is also not clear, it is ready for connect or it means connected? I
prefer to just use connected
Idle is also confusing, can we use avaiable?
And disconnect is also not so clear, It is disconnected from group? Or it is
disconnecting?
+
+ string Name [readonly]
+
+ Name of the peer.
We also need type, UI needs to show the device type.
And if the peer is group owner, In fact
It will join the group, so group information is also
Need. SSID, GO or GC
+
+ dict IPv4 [readonly]
+
+ string Address [readonly]
+
+ The current configured IPv4 address.
+ string Netmask [readonly]
Do we really need to export the peer IPV4 to user?
I think for Peer, MAC address is more useful
Maybe we need to explore local device IPV4 if the local device is GC.
Besides,
Could you also give out group API at same time?. Group operation is the key
operation in WiFi P2P, it is difficult for us to discuss WiFi P2P without group.
Thanks!
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
