Zitat von Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx>:
Hi Slawomir,
On Wed, Oct 5, 2011 at 6:20 PM, Slawomir Bochenski
<lkslawek@xxxxxxxxx> wrote:
On Wed, Oct 5, 2011 at 5:17 PM, Slawomir Bochenski
<lkslawek@xxxxxxxxx> wrote:
By removing this it wont flush on EOS, so Im not sure why you removed
it since OBEX_EV_REQ is only generated for the request not for the
streams itself. Actually if OpenOBEX had an event for that represent
the FINAL bit that would solve the problem with unknown size, but for
gobex this is exposed directly in the callback so I wouldn't change
that now.
You got this wrong, the purpose of this code is to flush on end of
stream not in the beginning/put request, so if we have consecutive
puts the last packet should cause a flush so the driver can sync any
buffered data before close which needs to be immediately.
Again, OBEX_EV_REQ will be the very _last_ thing called. This code
flushes after all write()-s. After the final packet.
To be specific: the order of events from openobex are OBEX_EV_REQHINT,
OBEX_EV_REQCHECK, multiple OBEX_EV_STREAMAVAIL (as we are starting
streaming in REQHINT), and then OBEX_EV_REQ.
I don't think this is true, if it was then why would we call
service->put on the end of stream and I also never see this happening
in practice e.g. calling ftp_put in the end of stream.
The order is correct. Actually, with openobex-1.5 it may happen that
you see one OBEX_EV_STREAMAVAIL before OBEX_EV_REQCHECK if a BODY
header is included in the first packet, and no OBEX_EV_REQCHECK if the
PUT has only one packet.
However, for current git (if a new version is ever going to be
released), this order is strictly correct if the request is not
aborted before being complete.
HS
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
