The folder property of PushMessages does not accept path information,
it allows only to request the messages to be added to a subfolder of the
current folder.
There does not seem to be any actual need for this method.
The current implementation calls Cancel when a pending
NewConnection() or RequestDisconnection() method call fails.
Additionally it calls Cancel() when the remote client has disconnected.
In either case BlueZ calls shutdown on the file descriptor associated
with the agent and issues a Cancel() method call.
The closing of the file descriptor will trigger a HUP on the agent side,
which will trigger normal cleanup procedures. The received Cancel()
method call is redundant in both cases.
The current implementation does not expect a reply, nor would it make
sense for BlueZ to wait for one from the agent. So explicitly label
this method as noreply.
There were two groups of missing error messages in the documentation:
* For org.bluez.Device1.DisconnectProfile:
This method could certainly call btd_error_not_supported or
btd_error_failed returning those errors.
* For org.bluez.Device1.Pair:
The pairing process could certainly call new_authentication_return
which can return (and actualy does) five other different errors.
Commit 826023de56 made some of the
device's properties optional but the documentation was not updated
accordingly. More specifically, the properties 'Name' and 'UUIDs' won't
be present if the information is not available.
Type now can assume the value "folder" so it is no longer necessary to
have Folder property, FolderType in introduced to provide the folder type
that before was on the Type itself.
In addition to this add proper documentation what properties are optional
and under what condition they are available.
This interface adds support for browsing and searching in the player's
storage using AVRCP 1.4/1.5.
Some remarks about the design:
- Exposing UIDCounter and UIDs was considered, but the spec seems to have
missed to define the player's id persistency. There are also the fact that
UIDCounter alone does not guarantee persistency across sessions and do not
provide what exact items have changed, so in the end exposing these
details will bring almost no value.
- Indexing or caching the whole media library is not recommended, Bluetooth
is too slow for that and even vendors such as Apple do not recommend doing
it, so the only items keep in cache are the current listed ones.
- Addressed vs Browsed player is done implicitly when accessed, this was done
to simplify the API and avoid confusions between applications and players.
This adds methods such as Play, Pause directly in MediaPlayer1, in
addition to that Track is now turn into a property to take advantage of
ObjectManager and document the interface as experimental.
