Hi Daniel,
Hi Tomasz,
On 07/04/2014 03:05 PM, Tomasz Bursztyka wrote:
As soon as p2p technology is present, whether it is enabled or not, it
will be possible to register and un-register P2P Peer services. These
will be served once p2p technology gets enabled.
When scanning for Peers is possible, Peer objects will show the proposed
services of those if some are present.
---
doc/manager-api.txt | 31 +++++++++++++++++++++++++++++++
doc/peer-api.txt | 5 +++++
2 files changed, 36 insertions(+)
diff --git a/doc/manager-api.txt b/doc/manager-api.txt
index 05d2701..3034c1e 100644
--- a/doc/manager-api.txt
+++ b/doc/manager-api.txt
@@ -156,6 +156,37 @@ Methods dict GetProperties()
Possible Errors: [service].Error.InvalidArguments
+ void RegisterPeerService(array{byte} specification, boolean
master) [experimental]
+
+ Registers a local P2P Peer service
+
+ If p2p technology is not available, this will raise an
+ error on such support.
I have troubles to parse this '... on such support'. Should that read
'not supported'?
I might rephrase this yes, will send another version
This behavior does not apply if
+ such technology is just disabled.
+
+ A Peer service belongs to the process that registers
+ it, thus if that process dies, its Peer services will
+ be destroyed as well.
+
+ "specification" is the TLV formated byte array
+ describing the P2P service.
Is there a special meaning behind the different writtings of p2p vs P2P?
p2p is for the connman's technology. P2P if for the concrete technology.
Don't know
if it matters to make such differentiation actually. I could write all
as 'p2p' directly.
+
+ Connman will be able to determine in most cases
ConnMan
+ whether to be the P2P Group Owner or not.
I am ignorant to p2p: Should'nt the rules when ConnMan is Group Owner or
not be documented?
You are right, ConnMan hides most of the p2p group but when proposing
services
there are really particular case when ConnMan cannot decide on its own
to be the GO or not,
for instance some vendor specific service that would strictly require to
be the GO. Thus this
entry here, there is no other way. And thus the explanation below as well.
If the
+ service must belong to a group that this device
+ manages, the "master" property can be set. Do not set
+ the "master" property unless you are absolutely sure
+ you know what you are doing.
+
+ Possible Errors: [service].Error.InvalidArguments
+ [service].Error.NotSupported
+
+ void UnregisterPeerService(array{byte} specification)
[experimental]
+
+ Unregisters an existing local P2P Peer service
+
+ Possible Errors: [service].Error.InvalidArguments
+
Signals TechnologyAdded(object path, dict properties)
Signal that is sent when a new technology is added.
diff --git a/doc/peer-api.txt b/doc/peer-api.txt
index e38066f..59a3351 100644
--- a/doc/peer-api.txt
+++ b/doc/peer-api.txt
@@ -57,3 +57,8 @@ Properties string State [readonly] [experimental]
string Netmask [readonly]
The current configured IPv4 netmask.
+
+ array{array{byte}} Services [readonly] [experimental]
+
+ Array of P2P service specifications, which are
+ themselves a TLV formated byte array.
I wonder if it would make sense to have a or two paragraph in
wifi-p2p-overview.txt explaining this interface. I am pretty sure some
guys will ask for examples :D
Sure, will do that when implementing this API.
Tomasz
_______________________________________________
connman mailing list
[email protected]
https://lists.connman.net/mailman/listinfo/connman
