Hi, On Sat, Oct 9, 2010 at 11:35 PM, Hendrik Sattler <p...@hendrik-sattler.de> wrote: > Am Samstag 09 Oktober 2010, 16:20:03 schrieb Luiz Augusto von Dentz: >> On Fri, Oct 8, 2010 at 7:38 PM, Hendrik Sattler <p...@hendrik-sattler.de> > wrote: >> > Am Freitag 08 Oktober 2010, 14:58:31 schrieb Luiz Augusto von Dentz: >> >> From: Luiz Augusto von Dentz <luiz.dentz-...@nokia.com> >> >> >> >> This make possible to cancel pending operation with a proper error >> >> instead of always respond using OBEX_RSP_UNAUTHORIZED. >> > >> > Changing obex_cancelrequest() is not the right aproach for that. >> > OBEX_CMD_ABORT is the only way to tell the other side that you want to >> > cancel a request. What other command do you want to use? >> >> Not really, first we cannot respond with abort because it is a >> response not a request, second OBEX_ObjectSetRsp doesn't work either >> because we normally are in the middle of stream transfer.
Not really, OBEX_ObjectSetRsp makes no difference, once I call OBEX_ResumeRequest it completely ignores the response set and got ahead and ask for more data with OBEX_EV_STREAMAVAIL, with OBEX_CancelRequest it should be possible to forcefully cancel any suspend request without having to resume it and deal with more events. > Especially with stream transfers, this is easy. You get the > OBEX_EV_STREAMAVAIL event and can react to it. > I see a problem in lib/obex_server.c when using buffered data mode > (OBEX_EV_PROGRESS comes to late to set a different response) but that can be > fixed. > >> It could be >> made by setting OBEX_ObjectSetRsp and than cancel request so that we >> mark the object->abort which are latter check on send, but if it is a >> general error which is not related to the object itself I find it odd >> to have to set the response via OBEX_ObjectSetRsp which takes the >> object pointer, that why I opt for canceling it directly via cancel so >> we can completely ignore whatever response is set on object, actually >> if we decide not to use nice as response on server than >> OBEX_CancelRequest is useless for servers which should always use >> OBEX_ObjectSetRsp + OBEX_ResumeRequest instead (we still have to fix >> it tough). > > If you are on the server side, you either don't like a request (represented by > _one_ obex_object) or you accept it. Both is realized with > OBEX_ObjectSetRsp(). Well this doesn't work for asynchronous requests for obvious reason, e.g. pbap requests which happens to access database via backend, Im afraid people get used to handle this via threads only and forget about people using a single mainloop to handle this. > Using OBEX_CancelRequest() on the server side seems strange since you have > never sent a request (and thus cannot cancel it). You can only respond to the > client with "no I don't your crap because..." or do it not-so-nice by killing > the connection hard. That's all your options as a server. You mean that as a server one cannot suspend a request while it does some processing e.g. call some other process and then resume once done? Also for expensive requests such as pbap that normally require backends to access data it is absolutely necessary to have a mean to cancel without depending on threads which are completely overkill for a simple daemon. > HS > > BTW: (self->state & MODE_SRV) should be (self->mode == MODE_SRV) Yep, this one I need to fix. -- Luiz Augusto von Dentz Computer Engineer ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb _______________________________________________ Openobex-users mailing list Openobex-users@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/openobex-users
