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?
> > 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.
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
