> 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
