the openobex users mailing list

Piotr Zgórecki | 21 Jun 2011 18:56

Commit 1dfa8c72affeba8abc87b43bcdf68360e91f1c66: Add support for SRM flags

Hi,

I played a bit with the obex_test program to understand OpenOBEX and
PUTs wouldn't work.
That's because the test app doesn't append an empty BODY header at the
end, which is now required with API changes introduced by the
aforementioned commit to properly generate an END_BODY. So - a few
questions:

1. All existing users of the library will obviously suffer the same -
is this intentional ?
2. I'm trying to understand the merit of the change and I think I'm
missing something - the commit message says it's for applications to
be able to insert headers in between BODY headers. However, given that
both obex_object_addheader() and obex_object_send() seem to preserve
the order of headers fed by the application that ability had always
been there. Are there any scenarios I'm missing ?

Cheers,
Piotr

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev

headers

Hendrik Sattler | 21 Jun 2011 23:02

Re: Commit 1dfa8c72affeba8abc87b43bcdf68360e91f1c66: Add support for SRM flags

Am Dienstag, 21. Juni 2011, 18:56:30 schrieb Piotr Zgórecki:
> Hi,
> 
> I played a bit with the obex_test program to understand OpenOBEX and
> PUTs wouldn't work.
> That's because the test app doesn't append an empty BODY header at the
> end, which is now required with API changes introduced by the
> aforementioned commit to properly generate an END_BODY. So - a few
> questions:
> 
> 1. All existing users of the library will obviously suffer the same -
> is this intentional ?

No, it is not.

> 2. I'm trying to understand the merit of the change and I think I'm
> missing something - the commit message says it's for applications to
> be able to insert headers in between BODY headers. However, given that
> both obex_object_addheader() and obex_object_send() seem to preserve
> the order of headers fed by the application that ability had always
> been there. Are there any scenarios I'm missing ?

Yes. The receiver might interpret the END-OF-BODY header as the end of the 
object, as specified by the OBEX spec.
The intention was to not send an END-OF-BODY header if there are other headers 
after the BODY header _at_ _the_ _time_ that the stream is empty.

I take a look at it.

HS

(Continue reading)

headers

Hendrik Sattler | 22 Jun 2011 11:23

Re: Commit 1dfa8c72affeba8abc87b43bcdf68360e91f1c66: Add support for SRM flags

Zitat von Piotr Zgórecki <pzgorecki <at> gmail.com>:
> I played a bit with the obex_test program to understand OpenOBEX and
> PUTs wouldn't work.
> That's because the test app doesn't append an empty BODY header at the
> end, which is now required with API changes introduced by the
> aforementioned commit to properly generate an END_BODY. So - a few
> questions:
>
> 1. All existing users of the library will obviously suffer the same -
> is this intentional ?
> 2. I'm trying to understand the merit of the change and I think I'm
> missing something - the commit message says it's for applications to
> be able to insert headers in between BODY headers. However, given that
> both obex_object_addheader() and obex_object_send() seem to preserve
> the order of headers fed by the application that ability had always
> been there. Are there any scenarios I'm missing ?

The bug for non-streaming is in obex_objec.c, line 417. The logic in  
inverted. It should be like in line 365.

With streaming mode, there seems to also be a bug but only if you are  
trying to use it more advanced than it was possible with v1.5 (mixing  
body headers with other headers).

Do you want to send patches or shall I do?

HS

------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.

(Continue reading)