Zitat von "Johan Hedberg" <johan.hedb...@gmail.com>: > The patches have been pushed upstream. I didn't actually test them in > practice, so I hope you've done that thoroughly ;)
I'm sure that there are some bugs left, I am not perfect, after all :) I tested with my obexpushd and obexftp, once with my USB AT modem emulation custom transport (obexftp -t /dev/ttyACM0) and with local TCP connection (obexftp -n 127.0.0.1). I haven't figured out how to get a Bluetooth local loop (that actually uses the bluetooth stack). Also using dummy_hcd.ko with g_serial use_acm=0 use_obex=1 randomly crashes, so I am not using it. Thanks to Hui Li for showing how to use SRM :) Maybe he can provide a patch for a native OBEX-over-L2CAP at least for the Linux case (then I can also look up how to do this for Windows case if possible at all). Note: with those patches, an OBEX server _always_ gets a EV_REQCHECK. I see this as necessary for being fully consistent as the app usually doesn't care if an event is single-packet or multi-packet. Additionally, setting the response to CONTINUE/SUCCESS is now _required_. It saves a lot of work for requests that are not wanted and makes it a lot easier for the application to not do anything wrong. I will do some documentation updates to tighten the description of all events and what to do there. > I also pushed a code/coding style cleanup patch on top of these, but to > be fair a lot of the cleanup (maybe even most) wasn't related to issues > introduced by your patches but existed in the code from before. While > going through the code I noticed that it could still use quite a lot of > refactoring in order to get rid of deeply nested if-statements, etc. > It's by far the most common cause of it being almost impossible to > adhere to the "max 79 columns" rule everywhere. I don't like the style but I don't care enough, either. But please do NOT do the following: - int type = SOCK_STREAM; - int proto = 0; + int type = SOCK_STREAM, proto = 0; Please do not insist on some kernel coding style stupidities, I may as well insist on MISRA rules, then ;) The above syntax: * makes it harder than necessary to change the type of e.g. proto * is much harder to read * is usually done wrong then using pointer types * does not conform to any sane coding ruleset, really HS ------------------------------------------------------------------------------ What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d _______________________________________________ Openobex-users mailing list Openobex-users@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/openobex-users
