From: Johan H. <joh...@gm...> - 2008-10-31 08:41:00
|
Hi, With the recent preparation for the openobex 1.4 release and fixing issues we've found in the context of obexd development, I ended up having to change the way that the return value of obex_object_send() (from lib/obex_object.c) is handled within obex_client() (lib/ obex_client.c). It seems that obex_object_send will return 1 only if the last packet of the object was sent and 0 otherwise (or -1 on error). This means that we should be in STATE_REC and not STATE_SEND after obex_object_send returns 0. Without this change we were seeing two consecutive PUT packets without any intermediate "continue" packet with our obex client (obex-client from the obexd package). This change seems to work fine in our tests, but because it changes code which has been for a long time in openobex I decided to write this email to see if people see any potential issues with it and have a chance to test it with their code before the next official openobex version goes out. Johan |
From: Marcel H. <ma...@ho...> - 2008-11-03 04:32:44
|
Hi guys, > With the recent preparation for the openobex 1.4 release and fixing > issues we've found in the context of obexd development, I ended up > having to change the way that the return value of obex_object_send() > (from lib/obex_object.c) is handled within obex_client() (lib/ > obex_client.c). > > It seems that obex_object_send will return 1 only if the last packet > of the object was sent and 0 otherwise (or -1 on error). This means > that we should be in STATE_REC and not STATE_SEND after > obex_object_send returns 0. Without this change we were seeing two > consecutive PUT packets without any intermediate "continue" packet > with our obex client (obex-client from the obexd package). > > This change seems to work fine in our tests, but because it changes > code which has been for a long time in openobex I decided to write > this email to see if people see any potential issues with it and have > a chance to test it with their code before the next official openobex > version goes out. so I am ready to release openobex-1.4, but I wanna have everybody to check that the current GIT tree is good enough and that we didn't break something. So please give feedback. Regards Marcel |
From: Hendrik S. <po...@he...> - 2008-11-03 08:20:59
|
Am Monday 03 November 2008 05:32:35 schrieb Marcel Holtmann: > Hi guys, > > > With the recent preparation for the openobex 1.4 release and fixing > > issues we've found in the context of obexd development, I ended up > > having to change the way that the return value of obex_object_send() > > (from lib/obex_object.c) is handled within obex_client() (lib/ > > obex_client.c). > > > > It seems that obex_object_send will return 1 only if the last packet > > of the object was sent and 0 otherwise (or -1 on error). This means > > that we should be in STATE_REC and not STATE_SEND after > > obex_object_send returns 0. Without this change we were seeing two > > consecutive PUT packets without any intermediate "continue" packet > > with our obex client (obex-client from the obexd package). > > > > This change seems to work fine in our tests, but because it changes > > code which has been for a long time in openobex I decided to write > > this email to see if people see any potential issues with it and have > > a chance to test it with their code before the next official openobex > > version goes out. > > so I am ready to release openobex-1.4, but I wanna have everybody to > check that the current GIT tree is good enough and that we didn't > break something. So please give feedback. Alex' patch 139683f9ca864a8e4fcfaf3a454c293539547903 fails to build on msvc because it doesn't like those defines like WMC_DEFAULT_OBEX_SERVER_UUID that are used as memory area later (and not just as initialiser). I am preparing a patch to fix this, moving this define to a static const array from usbobex.h to usbobex.c (it's only used once, there). Any objections? HS |
From: Marcel H. <ma...@ho...> - 2008-11-03 08:52:30
|
Hi Hendrik, >>> With the recent preparation for the openobex 1.4 release and fixing >>> issues we've found in the context of obexd development, I ended up >>> having to change the way that the return value of obex_object_send() >>> (from lib/obex_object.c) is handled within obex_client() (lib/ >>> obex_client.c). >>> >>> It seems that obex_object_send will return 1 only if the last packet >>> of the object was sent and 0 otherwise (or -1 on error). This means >>> that we should be in STATE_REC and not STATE_SEND after >>> obex_object_send returns 0. Without this change we were seeing two >>> consecutive PUT packets without any intermediate "continue" packet >>> with our obex client (obex-client from the obexd package). >>> >>> This change seems to work fine in our tests, but because it changes >>> code which has been for a long time in openobex I decided to write >>> this email to see if people see any potential issues with it and >>> have >>> a chance to test it with their code before the next official >>> openobex >>> version goes out. >> >> so I am ready to release openobex-1.4, but I wanna have everybody to >> check that the current GIT tree is good enough and that we didn't >> break something. So please give feedback. > > Alex' patch 139683f9ca864a8e4fcfaf3a454c293539547903 fails to build > on msvc > because it doesn't like those defines like > WMC_DEFAULT_OBEX_SERVER_UUID that > are used as memory area later (and not just as initialiser). > I am preparing a patch to fix this, moving this define to a static > const array > from usbobex.h to usbobex.c (it's only used once, there). > Any objections? go ahead. I didn't like them either, but was just too lazy to deal with it. Regards Marcel |
From: Hendrik S. <po...@he...> - 2008-11-03 08:53:06
|
Hi, This patch fixes (again) compiling on win32. Tested with MSVC7/8/9 and with gcc on linux. HS -- MSVC doesn't like define that are use like normal variables, e.g. as argument to memcmp(). This patch makes the define an initializer and adds a const variable. --- lib/usbobex.c | 3 ++- lib/usbobex.h | 4 ++-- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/lib/usbobex.c b/lib/usbobex.c index 3d1f619..b12131b 100644 --- a/lib/usbobex.c +++ b/lib/usbobex.c @@ -242,10 +242,11 @@ static void find_obex_service_descriptor(unsigned char *buffer, int buflen, obex else if (*service == NULL) { *service = malloc(sizeof(obex_usb_intf_service_t)); if (*service != NULL) { + const uint8_t default_uuid[16] = WMC_DEFAULT_OBEX_SERVER_UUID; (*service)->role = buffer[3]; memcpy((*service)->uuid, buffer+4, 16); (*service)->version = (buffer[20]<<8)|(buffer[21]); - if (memcmp((*service)->uuid, WMC_DEFAULT_OBEX_SERVER_UUID, 16) == 0 ) + if (memcmp((*service)->uuid, default_uuid, 16) == 0 ) (*service)->is_default_uuid = 1; else (*service)->is_default_uuid = 0; diff --git a/lib/usbobex.h b/lib/usbobex.h index f3ffbd4..efd7a38 100644 --- a/lib/usbobex.h +++ b/lib/usbobex.h @@ -82,11 +82,11 @@ struct cdc_union_desc { #define USB_DT_CS_INTERFACE 0x24 #define CDC_DATA_INTERFACE_TYPE 0x0a -#define WMC_DEFAULT_OBEX_SERVER_UUID ((const uint8_t []) \ +#define WMC_DEFAULT_OBEX_SERVER_UUID \ { 0x02, 0xae, 0xb3, 0x20, \ 0xf6, 0x49, 0x11, 0xda, \ 0x97, 0x4d, 0x08, 0x00, \ -0x20, 0x0c, 0x9a, 0x66 } ) +0x20, 0x0c, 0x9a, 0x66 } #define USB_MAX_STRING_SIZE 256 #define USB_OBEX_TIMEOUT 10000 /* 10 seconds */ -- 1.5.6.5 |
From: Marcel H. <ma...@ho...> - 2008-11-03 09:12:39
|
Hi Hendrik, > This patch fixes (again) compiling on win32. Tested with MSVC7/8/9 and > with gcc on linux. patch has been applied. Thanks. However next time, please create a new thread with a proper subject for it. Otherwise git-am does the wrong thing. Regards Marcel |
From: Hendrik S. <po...@he...> - 2008-11-03 09:17:24
|
Am Monday 03 November 2008 05:32:35 schrieb Marcel Holtmann: > Hi guys, > > > With the recent preparation for the openobex 1.4 release and fixing > > issues we've found in the context of obexd development, I ended up > > having to change the way that the return value of obex_object_send() > > (from lib/obex_object.c) is handled within obex_client() (lib/ > > obex_client.c). > > > > It seems that obex_object_send will return 1 only if the last packet > > of the object was sent and 0 otherwise (or -1 on error). This means > > that we should be in STATE_REC and not STATE_SEND after > > obex_object_send returns 0. Without this change we were seeing two > > consecutive PUT packets without any intermediate "continue" packet > > with our obex client (obex-client from the obexd package). > > > > This change seems to work fine in our tests, but because it changes > > code which has been for a long time in openobex I decided to write > > this email to see if people see any potential issues with it and have > > a chance to test it with their code before the next official openobex > > version goes out. > > so I am ready to release openobex-1.4, but I wanna have everybody to > check that the current GIT tree is good enough and that we didn't > break something. So please give feedback. To make it easier for you: here's the patch to update the project version for the CMake build files. This does not update the autotools files like configure.ac and doc/Doxyfile. HS -- From 36ce1e8912d5fdb01a137dd626c39c821868f8e6 Mon Sep 17 00:00:00 2001 From: Hendrik Sattler <po...@he...> Date: Mon, 3 Nov 2008 10:11:41 +0100 Subject: [PATCH] Prepare for releasing version 1.4 (cmake build files) --- CMakeLists.txt | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/CMakeLists.txt b/CMakeLists.txt index a079379..170c577 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -6,7 +6,7 @@ project ( openobex C ) # The project version # set ( VERSION_MAJOR 1 ) -set ( VERSION_MINOR 3 ) +set ( VERSION_MINOR 4 ) set ( VERSION_PATCH 0 ) set ( SHORT_VERSION "${VERSION_MAJOR}.${VERSION_MINOR}" ) -- 1.5.6.5 |
From: Hendrik S. <po...@he...> - 2008-11-03 09:19:22
|
Hi, forget that, I'll resend as new thread :) HS |