Hi, On Mon, Oct 11, 2010 at 1:59 PM, Hendrik Sattler <p...@hendrik-sattler.de> wrote: > Zitat von "Luiz Augusto von Dentz" <luiz.de...@gmail.com>: >> >> You mean OBEX_ResumeRequest take the response, > > That's not what I meant. With OBEX_SuspendRequest(), you can choose the > object to use, with OBEX_ResumeRequest(), it always is the current one. > >> that could work but of >> course we will need to change the logic so that it doesn't always try >> to resume the stream, taking the object sound good to me. But note >> that OBEX_ObjectSetRsp is still needed when request are not suspended, >> so if I were to deprecated anything it would be > > No, I meant to replace > OBEX_ObjectSetRsp(object, rsp, lastrsp) > with > OBEX_SetResponse(self, object-or-NULL, rsp, lastrsp) > so it matches the use-cases of SuspendRequest and ResumeRequest.
Hmm, that actually sounds like a nice idea, if we fix ResumeRequest. But what if there is something added to the object headers/body and I set a response other than Continue/Success? (more bellow) > BTW: > There is no need for a new obex_object for a server, use the present one in > your patch. > And then suddently, it is the same as an OBEX_SetResponse() (the actual > sending is done in OBEX_ResumeRequest()). That doesn't seems to work for me, OBEX_ResumeRequest calls obex_object_send which seems try to read/write more data, not sure if is by design or a bug, maybe OBEX_SetResponse should set something else in the object to make it skip additional events. Anyway this doesn't seems to be always the right thing to do, if there is a general error and/or there is a plugin holding a reference to the object pointer it is safer to call OBEX_CancelRequest and have the original object marked as aborted similar to receiving an ABORT before responding, in that case we want to differentiate a normal response (may have headers/data) from a response generated by cancel. >> OBEX_ResumeRequest/OBEX_SuspendRequest/OBEX_CancelRequest making >> openobex to never respond/request automatically to requests/responses, >> or if this is too much to start with we can just make some API change >> so the user application can request to operate on asynchronous >> (MainLoop based) or synchronous (thread based) mode. > > I kind of like the automatic "sending responses" behind the scenes... Personal preferences normally doesn't count, we need technical arguments, automatic response do cause problems for application which doesn't want them to be automatically, PBAP and MAP probably fit here, also protocols (even in case of IPCs) tend to be asynchronous by design and OBEX is no exception. Actually it will get even more asynchronous with Single Response Mode where the automatically responses are not needed and the protocol itself have support for suspend/resume, to me this sounds like a much stronger technical argument for the matter. -- 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
