On 23/08/2010 21:00, Chris Frey wrote > First of all, thanks very much for this patch. It looks well written > and can almost be applied as-is. I have some specific comments that > should be fixed first, below. Hi Chris,
Thanks for your quick reply, it's appreciated. > > What would be even more super would be a documented example of how to > use this, which could be added to the HTML docs under doc/www/. Sure, I'm happy to write some HTML docs on it. The only reason I hadn't already is I'd managed to entirely miss the documentation in there! > > Feel free to post the log snippet here, but even if we know what command > is causing the problem, the fix would have to be on RIM's side, no? I'll email a separate email about this but Windows with the RIM BlackBerry desktop manager seems to cope fine, so it is some combination of the BlackBerry firmware, usb_storage driver and the raw channel negotiation code (and is possible related to the issue you mentioned here: http://sourceforge.net/mailarchive/forum.php?thread_name=20100720033014.GA22722%40foursquare.net&forum_name=barry-devel <http://sourceforge.net/mailarchive/forum.php?thread_name=20100720033014.GA22722%40foursquare.net&forum_name=barry-devel>). My replies to your comments follow (with the ones I agree entirely with removed): > > Please try to follow existing tabs and coding style. Sorry, thought I'd cleaned all that up. >> ... >> + strcpy(modeName, explicitModeName); > Make sure that explicitModeName is not longer than the modeName buffer. > Good point, I feel a bit silly for not noticing that. > I see a lot of thread support classes... wondering what is the best > way to handle this code. What do you think of moving it into > the library? Yes. I'd be happy to move it into the library if you're happy for some pthread wrapping code to be in there. > Perhaps we should just fix SocketRoutingQueue! :-) > > What precisely is SocketRoutingQueue missing? The problem with SocketRoutingQueue in it's current form is that if it gets an error in SocketRoutingQueue::SimpleReadThread() it only outputs to the error stream; there doesn't seem to be a way (other than providing some clever ostream as the error stream) to get notified of these errors currently. I did consider adding an error callback to SocketRoutingQueue, but then realised that I couldn't do that without changing the size of the SocketRoutingQueue object and therefore breaking compatibility with code compiled against the old SocketRoutingQueue. Or do you think it would be ok to modify SocketRoutingQueue to add a read error callback in a way which would require recompilation by users of libbarry? Thank you for your comments once again and I'll send another email when I've made the suggested changes. Regards, Toby ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d _______________________________________________ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
