On Thu, Oct 6, 2011 at 10:17 AM, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > Hi Hendrik, > > On Thu, Oct 6, 2011 at 10:44 AM, Hendrik Sattler > <post@xxxxxxxxxxxxxxxxxx> wrote: >> 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. > > Yep, so obexd is broken for quite some time, since we do check also on > OBEX_EV_REQ, but the documentation is not very clear about it since it obexd works as it should. The code is coping with this by doing a buffering on behalf of a service driver if the service driver is not using chkput. So from the service perspective it will be still put, open, write, as the actual writing to mime driver is started at obex_put_stream_start. > says: > > /* An incoming request has arrived */ > > Also it doesn't help that OpenOBEX has tree events with similar > interpretation and probably because REQCHECK is not always generate we > had to have a proper check also on REQ too. Well I guess this is > another reason to move on and start porting the server side to gobex > which is much more mainloop friendly and less confusing is this > aspect. > > -- > 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 > -- Slawomir Bochenski -- 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
