On Thu, 2008-10-16 at 21:46 -0400, Chris Frey wrote: > On Wed, Oct 08, 2008 at 06:32:42AM -0400, Rick Scott wrote: > > I think we are on the same page here. My thought is to handle the socket > > 0 stuff in the module and have a device file created for all the other > > sockets that get opened. So far, "RIM Desktop" and "Usb_SerData". The > > desktop socket would peal off the usb type header, socket and length, > > and replace it with the serial header, 3 constant bytes and a checksum. > > That would give a consistent interface to the device on usb, bluetooth, > > and serial. Record parsing and a database "file system" would be better > > left to a fuse implementation, I think. It would be cool though, just > > cat a vCard into a file :) > > This would be quite useful. > > > > I've got a loadable module building outside of the kernel tree, so > > control would still be outside of the kernel process. > > Is this available in CVS somewhere? How far have you gotten?
Not yet in CVS, need to put the copyright stuff in. I have a desktop tty device created, XmBlackberry can handshake a connection and get the command table. > > > > > But it *would* be very useful to do something like this: > > > > > > start a backup > > > start a tethered modem connection > > > end backup > > > start a javaloader transfer > > > start a restore > > > end restore > > > do a full sync of contacts and calendar > > > end javaloader > > > end modem > > > > > > There are some gotcha's in that list, I think. :-) Should be doable in > > > theory though. > > > > Take out the javaloader part and it's doable now. > > Not quite. :-) The only way to do all of the above, in the same above > sequence, is to have a kernel module or background daemon handling the > shared USB traffic, as I understand it. > > Here are the conflicts: > > - the backup requires interface class 255, and the Desktop socket > > - the tethered modem requires interface class 255, for both the > IPModem and Serial modes... if backup and tethered modem > are separate programs, like Barry does it, this is a problem. > If they are all handled in the same program, like XmBlackBerry, > this is possible, but you run into a problem when syncing > (see below) > > - javaloader... I'm assuming another interface class 255 conflict > > - doing a full sync requires a disconnect and reconnect of the > Desktop mode, in order to update the database's dirty > flags... if there is a smarter way of doing this, it would > make things a lot cleaner. At the moment, due to a > lack of a complete understanding of the Probe messages, > it can be tricky to properly do this reconnect. > This could use more testing, as I haven't touched it in > a while, but Barry's opensync plugin currently does an > entirely new probe to do this reconnect. XmBlackBerry can disconnect from Desktop then reconnect while leaving the modem active. Not sure if the flags get updated, but you can use the device while it is tethered .... > > With a thin kernel driver, or daemon, that could handle all these > background conflicts, and also do the header strip/replace you talked > about, this would make things a lot more flexible, and would make it > easier to share the Blackberry across multiple programs. > > As I understand it, even RIM has to have its Desktop Manager running > in the background on Windows for all this. :-) > > - Chris ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
