From: Eric L. <Eri...@ac...> - 2007-12-03 10:34:42
|
Hi, The fix Frederic proposed is actually not good. There is a problem when the event callback starts a new request. For example, I use the CONNECT EV_REQDONE to start a new PUT request, and that would fail with this change. The new PUT request initializes the state as it likes and then the event callback returns. But at this time, the state would be overridden with MODE_SRV. Let me summarize the last changes: At changestate 262, the state initialization was moved before calling obex_deliver_event. This was bad because obex_deliver_event uses it to determine the current mode. So it broke all the code who actually use the mode parameter in the event callback. Frederic proposed to move the state initialization after obex_deliver_event. This is the patch Christian W. Zuckschwerdt said he put on his todo list. But it is also bad to set the state after obex_deliver_event for the reason I mentioned above. I think the right way to fix this is to pre-initialize the next state before calling obex_deliver_event, and to pass the current state to obex_deliver_event as follows: OLD IMPLEMENTATION ------------------ void obex_deliver_event(obex_t *self, int event, int cmd, int rsp, int del) { obex_object_t *object =3D self->object; if (del =3D=3D TRUE) self->object =3D NULL; if (self->state & MODE_SRV) self->eventcb(self, object, OBEX_MODE_SERVER, event, cmd, rsp); else self->eventcb(self, object, OBEX_MODE_CLIENT, event, cmd, rsp); =09 if (del =3D=3D TRUE) obex_object_delete(object); } NEW PROPOSED IMPLEMENTATION --------------------------- void obex_deliver_event(obex_t *self, int event, int cmd, int rsp, int del, int mode) { obex_object_t *object =3D self->object; if (del =3D=3D TRUE) self->object =3D NULL; self->eventcb(self, object, mode, event, cmd, rsp); =09 if (del =3D=3D TRUE) obex_object_delete(object); } I'm sorry I don't provide a patch file, but I'm fairly new to this open source development process and I'm not sure exactly how to proceed. I think however my explanation above is clear enough to understand. Don't hesitate to correct me if this is wrong. Eric. |
From: Eric L. <Eri...@ac...> - 2007-12-17 12:42:10
|
No comments on this one ? Eric. -----Original Message----- From: ope...@li... = [mailto:ope...@li...] On Behalf Of Eric = Lapuyade Sent: lundi 3 d=E9cembre 2007 11:35 To: ope...@li... Subject: Re: [openobex-users] OBEX_EV_REQDONE mode problem in cvs = version Hi, The fix Frederic proposed is actually not good. There is a problem when the event callback starts a new request. For example, I use the CONNECT EV_REQDONE to start a new PUT request, and that would fail with this change. The new PUT request initializes the state as it likes and then the event callback returns. But at this time, the state would be overridden with MODE_SRV. Let me summarize the last changes: At changestate 262, the state initialization was moved before calling obex_deliver_event. This was bad because obex_deliver_event uses it to determine the current mode. So it broke all the code who actually use the mode parameter in the event callback. Frederic proposed to move the state initialization after obex_deliver_event. This is the patch Christian W. Zuckschwerdt said he put on his todo list. But it is also bad to set the state after obex_deliver_event for the reason I mentioned above. I think the right way to fix this is to pre-initialize the next state before calling obex_deliver_event, and to pass the current state to obex_deliver_event as follows: OLD IMPLEMENTATION ------------------ void obex_deliver_event(obex_t *self, int event, int cmd, int rsp, int del) { obex_object_t *object =3D self->object; if (del =3D=3D TRUE) self->object =3D NULL; if (self->state & MODE_SRV) self->eventcb(self, object, OBEX_MODE_SERVER, event, cmd, rsp); else self->eventcb(self, object, OBEX_MODE_CLIENT, event, cmd, rsp); =09 if (del =3D=3D TRUE) obex_object_delete(object); } NEW PROPOSED IMPLEMENTATION --------------------------- void obex_deliver_event(obex_t *self, int event, int cmd, int rsp, int del, int mode) { obex_object_t *object =3D self->object; if (del =3D=3D TRUE) self->object =3D NULL; self->eventcb(self, object, mode, event, cmd, rsp); =09 if (del =3D=3D TRUE) obex_object_delete(object); } I'm sorry I don't provide a patch file, but I'm fairly new to this open source development process and I'm not sure exactly how to proceed. I think however my explanation above is clear enough to understand. Don't hesitate to correct me if this is wrong. Eric. -------------------------------------------------------------------------= SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 _______________________________________________ Openobex-users mailing list Ope...@li... http://lists.sourceforge.net/lists/listinfo/openobex-users |
From: Eric L. <Eri...@ac...> - 2008-01-02 16:56:54
|
One last try in hope to get some feedback... Anybody listening out = there? I'm just trying to offer my contribution. If there is no interest for = it, that's OK with me. Just tell me... Eric. -----Original Message----- From: ope...@li... = [mailto:ope...@li...] On Behalf Of Eric = Lapuyade Sent: lundi 17 d=E9cembre 2007 13:42 To: ope...@li... Subject: Re: [openobex-users] OBEX_EV_REQDONE mode problem in cvs = version No comments on this one ? Eric. -----Original Message----- From: ope...@li... = [mailto:ope...@li...] On Behalf Of Eric = Lapuyade Sent: lundi 3 d=E9cembre 2007 11:35 To: ope...@li... Subject: Re: [openobex-users] OBEX_EV_REQDONE mode problem in cvs = version Hi, The fix Frederic proposed is actually not good. There is a problem when the event callback starts a new request. For example, I use the CONNECT EV_REQDONE to start a new PUT request, and that would fail with this change. The new PUT request initializes the state as it likes and then the event callback returns. But at this time, the state would be overridden with MODE_SRV. Let me summarize the last changes: At changestate 262, the state initialization was moved before calling obex_deliver_event. This was bad because obex_deliver_event uses it to determine the current mode. So it broke all the code who actually use the mode parameter in the event callback. Frederic proposed to move the state initialization after obex_deliver_event. This is the patch Christian W. Zuckschwerdt said he put on his todo list. But it is also bad to set the state after obex_deliver_event for the reason I mentioned above. I think the right way to fix this is to pre-initialize the next state before calling obex_deliver_event, and to pass the current state to obex_deliver_event as follows: OLD IMPLEMENTATION ------------------ void obex_deliver_event(obex_t *self, int event, int cmd, int rsp, int del) { obex_object_t *object =3D self->object; if (del =3D=3D TRUE) self->object =3D NULL; if (self->state & MODE_SRV) self->eventcb(self, object, OBEX_MODE_SERVER, event, cmd, rsp); else self->eventcb(self, object, OBEX_MODE_CLIENT, event, cmd, rsp); =09 if (del =3D=3D TRUE) obex_object_delete(object); } NEW PROPOSED IMPLEMENTATION --------------------------- void obex_deliver_event(obex_t *self, int event, int cmd, int rsp, int del, int mode) { obex_object_t *object =3D self->object; if (del =3D=3D TRUE) self->object =3D NULL; self->eventcb(self, object, mode, event, cmd, rsp); =09 if (del =3D=3D TRUE) obex_object_delete(object); } I'm sorry I don't provide a patch file, but I'm fairly new to this open source development process and I'm not sure exactly how to proceed. I think however my explanation above is clear enough to understand. Don't hesitate to correct me if this is wrong. Eric. -------------------------------------------------------------------------= SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 _______________________________________________ Openobex-users mailing list Ope...@li... http://lists.sourceforge.net/lists/listinfo/openobex-users -------------------------------------------------------------------------= SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketpl= ace _______________________________________________ Openobex-users mailing list Ope...@li... http://lists.sourceforge.net/lists/listinfo/openobex-users |
From: Hendrik S. <po...@he...> - 2008-01-02 22:40:05
|
Am Mittwoch 02 Januar 2008 schrieb Eric Lapuyade: > One last try in hope to get some feedback... Anybody listening out there? > > I'm just trying to offer my contribution. If there is no interest for it, > that's OK with me. Just tell me... Listening for sure. What do you want to happen? > I'm sorry I don't provide a patch file, but I'm fairly new to this open > source development process and I'm not sure exactly how to proceed. I > think however my explanation above is clear enough to understand. Don't > hesitate to correct me if this is wrong. As already mentioned before: create a proper PATCH file. Eventually tested and submitted to zanys bug tracker. HS |
From: Eric L. <Eri...@ac...> - 2008-01-03 12:53:49
Attachments:
deliverevent.patch
|
What I expect to happen is that someone responsible for OpenObex comment on my proposition, and validate it or not. I have attached a patch file. The modifications have been tested successfully. I have also submitted a bug on sourceforge tracker for OpenObex. I hope this is what you expect. Eric. |
From: Hendrik S. <po...@he...> - 2008-01-03 19:26:01
|
Am Donnerstag 03 Januar 2008 schrieb Eric Lapuyade: > What I expect to happen is that someone responsible for OpenObex comment > on my proposition, and validate it or not. =46rom my POV, the changes make sense, didn't get too deep though. One comm= ent,=20 though: the (x? a: b) thing is repeated way too often. I'd suggest using a= =20 wrapper function for this case (or a #define), preferable with the old name= =20 (makes the patch a lot smaller and hides details) and call the function wit= h=20 the additional argument only for the cases where the mode is known better=20 from the caller. Like obex_deliver_event() stays unchanged (no mode argument) and calls=20 obex_deliver_event_ext() with the new mode argument (I am not good in namin= g=20 functions :-/ ). > I have attached a patch file. The modifications have been tested > successfully. > > I have also submitted a bug on sourceforge tracker for OpenObex. I hope > this is what you expect. Nah, use trac on www.openobex.org. The SF.net site has pretty low usability= =20 and zany prefers the trac one, I guess. Small and good changes/fixes usually make it in but patience is a requireme= nt=20 (e.g. the developers with CVS access can be very busy with real life). HS |
From: Eric L. <Eri...@ac...> - 2008-01-04 09:37:59
Attachments:
deliverevent_svn.patch
|
I hadn't seen the "Creating/submitting a patch" page on www.openobex.com so I did the patch again using svn diff (attached). I tried to register on www.openobex.com to file a new ticket, but it doesn't seem to work. The created account is not recognized (it exists though, as I got an "already existing account" when I tried to create it again). I don't see any place where I can say "password lost" (in case I mistyped the password twice), so I tried again with a second account, and same result. Without login in, it seems not possible to create a ticket. Eric. -----Original Message----- From: ope...@li... [mailto:ope...@li...] On Behalf Of Hendrik Sattler Sent: jeudi 3 janvier 2008 20:26 To: ope...@li... Subject: Re: [openobex-users] OBEX_EV_REQDONE mode problem in cvs version Am Donnerstag 03 Januar 2008 schrieb Eric Lapuyade: > What I expect to happen is that someone responsible for OpenObex comment > on my proposition, and validate it or not. >From my POV, the changes make sense, didn't get too deep though. One comment,=20 though: the (x? a: b) thing is repeated way too often. I'd suggest using a=20 wrapper function for this case (or a #define), preferable with the old name=20 (makes the patch a lot smaller and hides details) and call the function with=20 the additional argument only for the cases where the mode is known better=20 from the caller. Like obex_deliver_event() stays unchanged (no mode argument) and calls=20 obex_deliver_event_ext() with the new mode argument (I am not good in naming=20 functions :-/ ). > I have attached a patch file. The modifications have been tested > successfully. > > I have also submitted a bug on sourceforge tracker for OpenObex. I hope > this is what you expect. Nah, use trac on www.openobex.org. The SF.net site has pretty low usability=20 and zany prefers the trac one, I guess. Small and good changes/fixes usually make it in but patience is a requirement=20 (e.g. the developers with CVS access can be very busy with real life). HS ------------------------------------------------------------------------ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Openobex-users mailing list Ope...@li... http://lists.sourceforge.net/lists/listinfo/openobex-users |
From: Hendrik S. <po...@he...> - 2008-01-04 09:59:36
|
Am Freitag 04 Januar 2008 schrieb Eric Lapuyade: > I hadn't seen the "Creating/submitting a patch" page on www.openobex.com > so I did the patch again using svn diff (attached). > > I tried to register on www.openobex.com to file a new ticket, but it > doesn't seem to work. The created account is not recognized (it exists > though, as I got an "already existing account" when I tried to create it > again). I don't see any place where I can say "password lost" (in case I > mistyped the password twice), so I tried again with a second account, > and same result. > > Without login in, it seems not possible to create a ticket. Maybe the site admin (Christian) needs to ack that registration, first. My login works so the login mechanism itself is not broken. HS |
From: Christian W. Z. <Christian@Zuckschwerdt.org> - 2008-01-04 14:49:09
|
Hi Eric, first of all, thank you for your continued effort on this patch! You are not the first to mention a login problem at www.openobex.org (dev.zuckschwerdt.org). And the issue turned out to be some stale lighttpd config now (I switch back to apache a while back). I've reset (deleted) some accounts and BCC'ed all people. Sorry for the inconvenience. regards, Christian Eric Lapuyade schrieb: > doesn't seem to work. The created account is not recognized (it exists > though, as I got an "already existing account" when I tried to create it > again). I don't see any place where I can say "password lost" (in case I > mistyped the password twice), so I tried again with a second account, > and same result. > |
From: Hendrik S. <po...@he...> - 2008-01-11 13:46:39
|
Hi Eric, I took a close look now and maybe Zany can comment on that, too. Why at all is MODE_SRV used in lib/obex_client.c. This looks totally wrong. Actually, MODE_SRV and MODE_CLI should _only_ be set in lib/obex.c! Either you currently use a handle as client or as server. It should surely = be=20 possible to use the same obex handle for both but not at the same time! You= =20 can have more than one obex handle, though, each using the same callback. A patch could involve the following: - fix the STATE_* and MODE_* mixup in one variable: * either don't use the state enum (->unpredictable member values) but defines * use the state enum with assigned values (still ugly) * seperate mode and state variables in struct obex (**best**) - never set the MODE_* parts anywhere but in lib/obex.c, thus only set by * OBEX_Init (be MODE_SRV by default) * OBEX_ServerAccept (MODE_SRV) * OBEX_Request (MODE_CLI) Does that sound reasonable? HS |
From: Eric L. <Eri...@ac...> - 2008-01-11 15:32:53
|
As I understand it, MODE_SRV / MODE_CLI are not the same thing than OBEX_MODE_SERVER / OBEX_MODE_CLIENT. MODE_SRV / MODE_CLI are used to remember if we are sending the current cmd frame or receiving the cmd reply frame, no matter whether we are a CLIENT or a SERVER. OBEX_MODE_SERVER / OBEX_MODE_CLIENT are used to indicate the obex handle mode (client if we are sending requests, server if we are receiving requests). Eric. -----Original Message----- From: Hendrik Sattler [mailto:po...@he...]=20 Sent: vendredi 11 janvier 2008 14:46 To: ope...@li... Cc: Eric Lapuyade Subject: Re: [openobex-users] OBEX_EV_REQDONE mode problem in cvs version Hi Eric, I took a close look now and maybe Zany can comment on that, too. Why at all is MODE_SRV used in lib/obex_client.c. This looks totally wrong. Actually, MODE_SRV and MODE_CLI should _only_ be set in lib/obex.c! Either you currently use a handle as client or as server. It should surely be possible to use the same obex handle for both but not at the same time! You can have more than one obex handle, though, each using the same callback. A patch could involve the following: - fix the STATE_* and MODE_* mixup in one variable: * either don't use the state enum (->unpredictable member values) but defines * use the state enum with assigned values (still ugly) * seperate mode and state variables in struct obex (**best**) - never set the MODE_* parts anywhere but in lib/obex.c, thus only set by * OBEX_Init (be MODE_SRV by default) * OBEX_ServerAccept (MODE_SRV) * OBEX_Request (MODE_CLI) Does that sound reasonable? HS |
From: Hendrik S. <po...@he...> - 2008-01-11 17:59:33
|
Am Freitag 11 Januar 2008 schrieb Eric Lapuyade: > As I understand it, MODE_SRV / MODE_CLI are not the same thing than > OBEX_MODE_SERVER / OBEX_MODE_CLIENT. > > MODE_SRV / MODE_CLI are used to remember if we are sending the current > cmd frame or receiving the cmd reply frame, no matter whether we are a > CLIENT or a SERVER. > > OBEX_MODE_SERVER / OBEX_MODE_CLIENT are used to indicate the obex handle > mode (client if we are sending requests, server if we are receiving > requests). =46rom my understanding, they were supposed to be totally equal: one define= =20 exported to the application, one internal to the lib. Is a server ever sending commands? Not that I know of (only responses to=20 client requests). HS |
From: Eric L. <Eri...@ac...> - 2008-01-12 06:38:57
|
Yes. Once the connection is established, both endpoints can send requests. So OBEX_MODE_SERVER / OBEX_MODE_CLIENT is not even related to who connects/accept the connection. Eric. -----Original Message----- From: ope...@li... [mailto:ope...@li...] On Behalf Of Hendrik Sattler Sent: vendredi 11 janvier 2008 19:00 To: ope...@li... Subject: Re: [openobex-users] OBEX_EV_REQDONE mode problem in cvs version Am Freitag 11 Januar 2008 schrieb Eric Lapuyade: > As I understand it, MODE_SRV / MODE_CLI are not the same thing than=20 > OBEX_MODE_SERVER / OBEX_MODE_CLIENT. > > MODE_SRV / MODE_CLI are used to remember if we are sending the current > cmd frame or receiving the cmd reply frame, no matter whether we are a > CLIENT or a SERVER. > > OBEX_MODE_SERVER / OBEX_MODE_CLIENT are used to indicate the obex=20 > handle mode (client if we are sending requests, server if we are=20 > receiving requests). >From my understanding, they were supposed to be totally equal: one define exported to the application, one internal to the lib. Is a server ever sending commands? Not that I know of (only responses to client requests). HS |
From: Hendrik S. <po...@he...> - 2008-01-13 19:04:36
|
Am Samstag 12 Januar 2008 schrieb Eric Lapuyade: > Yes. Once the connection is established, both endpoints can send > requests. So OBEX_MODE_SERVER / OBEX_MODE_CLIENT is not even related to > who connects/accept the connection. Where in the OBEX specs is this stated? The obex spec actually says: "OBEX follows a client/server request-response paradigm for the conversation format. The terms client and server refer to the originator/receiver of the OBEX connection[...]. Requests are issued by the client (the party that initiates the OBEX connection). Once a request is issued, the client waits for a response from the server before issuing another request. The request/response pair is referred to as an operation." This paragraph is pretty simple and clear: An OBEX server is not allowed to issue requests. It may be possible to violate the specs but why should the library support that? HS |
From: Hendrik S. <po...@he...> - 2008-01-13 19:07:47
|
Am Sonntag 13 Januar 2008 schrieb Hendrik Sattler: > Am Samstag 12 Januar 2008 schrieb Eric Lapuyade: > > Yes. Once the connection is established, both endpoints can send > > requests. So OBEX_MODE_SERVER / OBEX_MODE_CLIENT is not even related to > > who connects/accept the connection. > > Where in the OBEX specs is this stated? > > The obex spec actually says: > "OBEX follows a client/server request-response paradigm for the > conversation format. The terms client and server refer to the > originator/receiver of the OBEX connection[...]. Requests are issued by the > client (the party that initiates the OBEX connection). Once a request is > issued, the client waits for a response from the server before issuing > another request. The request/response pair is referred to as an operation." > > This paragraph is pretty simple and clear: An OBEX server is not allowed to > issue requests. It may be possible to violate the specs but why should the > library support that? That said: Sure you can use OBEX_Request() if you server also wants to act as a client, but it has to use OBEX_Init() first to get another obex_t. HS |
From: Eric L. <Eri...@ac...> - 2008-01-14 09:32:23
|
OK, I wrote too fast. I should have taken the time to re-read all this. I got back to the spec. It says: > The terms client and server refer to the originator/receiver of the OBEX connection,=20 > not necessarily who originated the low level IrLAP connection. I guess this is where I got this (false) idea. So, an obex connection starts when a CONNECT_CMD has been sent and replied. The client is the one sending the CONNECT_CMD. The spec also says: >Each side of a communication link may have both client and server if desired, and thereby create a peer >to peer relationship between applications by using a pair of OBEX sessions, one in each direction. As you said, both sides must then call OBEX_Init and xxxOBEX_TransportConnect. They share the physical link using different sockets but that is all they have in common. So even though the spec does not explicitly prevent the server to send requests, I think you are right and it is safe to say that only the client can send requests. So it looks like some of my understanding was wrong. I suggest we start by discussing what MODE_SRV/MODE_CLI are, and what the exact meaning of the 'mode' parameter in the event callback is ? Eric: PS: There is also the following chapter that I don't really understand: 3.3.1.10 OBEX Operations without Connect It is highly recommended that implementations assume default values for connection parameters (currently just a minimum OBEX packet size of 255 bytes) and accept operations such as PUT and GET without first requiring a CONNECT operation. So, CONNECT seems not mandatory. If there is no CONNECT_CMD, how do you determine who the client is? -----Original Message----- From: ope...@li... [mailto:ope...@li...] On Behalf Of Hendrik Sattler Sent: dimanche 13 janvier 2008 20:08 To: ope...@li... Subject: Re: [openobex-users] OBEX_EV_REQDONE mode problem in cvs version Am Sonntag 13 Januar 2008 schrieb Hendrik Sattler: > Am Samstag 12 Januar 2008 schrieb Eric Lapuyade: > > Yes. Once the connection is established, both endpoints can send > > requests. So OBEX_MODE_SERVER / OBEX_MODE_CLIENT is not even related to > > who connects/accept the connection. > > Where in the OBEX specs is this stated? > > The obex spec actually says: > "OBEX follows a client/server request-response paradigm for the > conversation format. The terms client and server refer to the > originator/receiver of the OBEX connection[...]. Requests are issued by the > client (the party that initiates the OBEX connection). Once a request is > issued, the client waits for a response from the server before issuing > another request. The request/response pair is referred to as an operation." > > This paragraph is pretty simple and clear: An OBEX server is not allowed to > issue requests. It may be possible to violate the specs but why should the > library support that? That said: Sure you can use OBEX_Request() if you server also wants to act as=20 a client, but it has to use OBEX_Init() first to get another obex_t. HS ------------------------------------------------------------------------ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketp lace _______________________________________________ Openobex-users mailing list Ope...@li... http://lists.sourceforge.net/lists/listinfo/openobex-users |