GObexApparam abstract the handling of application parameter tags, it
can be used to read/parse application parameter header data using
g_obex_apparam_get_* functions or to generate the data using
g_obex_apparam_set_*.
If callback is provided in g_obex_cancel_transfer() current complete
callback will be replaced by the new one and user will be informed
when abort completes.
gobex was actually used to respond not to request so the test is
renamed to test_stream_put_rsp_abort and a new test is created using
g_obex_put_req to initiate the request and g_obex_cancel_transfer to
abort it.
ENOSYS correspond to function not implemented which is exactly what the
OBEX error code means.
Also since EINVAL means invalid argument that now map to OBEX bad request
This patch create a map between posix errors code and OBEX response
opcode and use it to generate a proper response in case a transfer
failed instead of always responding with internal error.
GOEP 2.0 test specification forbids the server to include SRM headers in
CONNECT response:
"3.16 TP/SRM/BI-03-C Process an OBEX CONNECT request (incorrectly)
containing a SRM header:
• Expected Outcome
Pass Verdict:
– On receiving the invalid SRM header in the OBEX_CONNECT request, the
IUT responds with a SUCCESS without a SRM header.
– OBEX/L2CAP channel is established.
Fail Verdict:
– On receiving the invalid SRM header in the OBEX_CONNECT request, the
IUT does not respond with a SUCCESS and/or includes a SRM header in the
response.
– OBEX/L2CAP channel is not established or OBEX/RFCOMM channel is
established."
Now that SRM is automatically configured when the transport type is
SOCK_SEQPACKET all tests that uses this transport are already testing
SRM so there is no need to keep adding the headers manually.
In addition to that remove the tests for SRM using SOCK_STREAM since
those are currently not supported without including the headers.
This simplifies the applications so SRM setup phase became transparent
while using SOCK_SEQPACKET which is useful for GOEP 2.0 since in that
case we can only use SRM if the transport is L2CAP.
This also follows GOEP 2.0 Page 14 - 4.6 Using Single Response Mode:
"The Server cannot issue an enable request, but can only issue a
response to an enable request from the Client. SRM will remain in
effect for the duration of the operation that enabled it (PUT or GET)
...
SRM headers shall not be sent in CONNECT request or response packets."
and Page 22 - 5.4 Establishment of OBEX Connection:
"SRM headers shall not be sent in the Connect request or response
packets (note, this is to preserve backwards compatibility). SRM shall
be enabled through Put and Get operations only."
So only in case of PUT or GET requests SRM is automatically configured,
applications can still enable it manually for other operations by adding
the headers like before but it is not recommended.
Note that it would be a good practice to indicate SRM support by using
value 0x02, but since that should happens during CONNECT command it is
not done automatically for requests when acting as a client, server
responding to indicate requests will automatically add SRM headers though.
The previous approach searched the transfer pointer itself, assuming
that the transfers has not been modified if the pointer is in the list.
However the callback could have removed the transfer and registered
another one, which can eventually point to the same memory location.
This is solved by looking for the transfer id instead of the pointer.
