All excellent points however .... We don't have an application that will talk to a blackberry! We have an application that will talk to a blackberry on the usb, we have one that will talk to one on bluetooth and serial but, we don't have one that will talk to a blackberry. This would be simple if RIM didn't cram a whole bunch of functions into a single usb interface. They did it right when they made storage a separate interface. They did it right when they made DUN and Desktop separate bluetooth services (okay, they messed up the ppp protocol, but they got close). They screwed the pooch when they multiplexed a bunch of services into a single usb interface. Even worse, is that these multiple services are on the same 2 endpoints. They simplified things somewhat by moving the modem access to its own set of endpoints. What I'm proposing is a thin module to simply de-multiplex the mess into separate devices. That way a single application can talk to the blackberry desktop by pointing it at the correct device file. The application will not have to know what type of interface the blackberry is attached to. It will also provide simultaneous access to the desktop, modem, and storage. All of this wonderful DBUS and HAL stuff will be simpler once the mess of multiple independent services in a single interface is fixed up.
On Wed, 2008-10-08 at 14:59 -0700, Chris Maresca wrote: > Could you not have a userspace application interrogate the BB when > plugged in? After all, you do know it's a Blackberry (or at least a RIM > device) from the HAL logs sent by Edge. > > There are also a bunch of identifiers that might identify the specific > device: > > - usb.serial > - usb.vendor_id > - usb.product_id > > So it might be easier to do than it seems. Then again, I don't really > know all that much about USB HAL, so perhaps these are just bogus settings. > > Chris. > > Martin Owens wrote: > >> Ah, now I think I understand better what you are thinking. You are > >> detecting the BB properties from user space and stuffing the info back > >> into the os (via hal) and using, or proposing to use, that info from > >> other apps. Am I close? > >> > > > > Indeed, Usability by applications is what I'm thinking. There is (as an > > example) an application called gtkpod which manages ipods. It uses hal > > via dbus to detect when an ipod is plugged in, yet because of the lack > > of information available in hal it has to ask the user what kind of ipod > > was just plugged in. (for compatibility I guess) > > > > At the moment we don't even have blackberry or syncing programs that are > > stable yet. But when we do, I don't want them doing the same thing. > > > > > >> If we extend this path, then I guess the most obvious way to access > >> the 'data' is via a file system layer that may look like > >> > >> /dev/bb/pim/various_databases > >> > > > > If you do offer this kind of thing, then put it in /sys instead of /dev, > > no point cluttering up the place. Then again, avoid the whole thing and > > keep it in user space, put add them as capabilities into hal. > > > > Capability 'tethering' links into the network manager and uses a general > > schema for phone tethering. > > > > Capability 'databases' provides ways to access multiple device > > databases, although nothing specific about what tables or fields, that > > would be handled by the app (such as an open-sync plugin) > > > > Capability 'mass-storage-device' already works, check it out as an > > example of how this kind of thing can be done. > > > > Regards, Martin > > > > > > ------------------------------------------------------------------------- > > 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 > > > > ------------------------------------------------------------------------- > 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 ------------------------------------------------------------------------- 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
