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. -- Luiz Augusto von Dentz -- 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
