1 This file contains features that need work. If you wish to tackle
2 any of them, please post a quick message to the mailing list of your
3 intentions, in order to avoid duplication of effort.
5 If you would like help or more information on any of these items,
6 please ask on the mailing list as well.
11 Next Release Checklist (- todo, + done, x skipped)
12 ==============================================================================
13 Target: the 0.18.x series
14 - continue adding better support for French and Spanish translations,
15 especially to the Desktop GUI
16 - desktop: add java management GUI
17 - website documentation:
18 - www documentation / howto for bjdwp and friends
19 - add docs for using libmtp with the Storm to access media
20 - polish up bfuse, and add feature to split out fields
22 Target: release version 0.19
23 - add record classes for Content Store based on
24 Martin Owens' doc/barry-research.ods
25 - look at incorporating contrib/ into main tree, or at least
26 into binary packages and tests
32 ==============================================================================
34 Add firmware upgrade support via USB
35 ------------------------------------
36 Duplicate the firmware upgrade functionality of the RIM Windows
37 software. There are USB captures of this in the USB Capture Log
38 archive at http://www.netdirect.ca/software/packages/barry/logs.php
41 Add media management via USB
42 ----------------------------
43 The Windows version of desktop software has the ability to manage
44 photos on the Blackberry that are not stored on a flash card, but
45 are instead stored in the Blackberry's internal memory.
47 It is challenging, on some devices, to even copy such photos and
48 media to the flash card.
50 Capture the USB traffic for this media management, and add support
54 Add HAL/dbus support to BarryBackup
55 -----------------------------------
56 The latest version of the backup program lists devices in a combo box,
57 with a Reload button to handle new devices being plugged in.
59 Add an optional feature to listen to HAL/dbus for device addition and
60 removal and update the list automatically. Note that this must be
61 optional, since some systems may not have HAL available at compile time
62 (such as FreeBSD) or perhaps at runtime (HAL may not be running),
63 and so the Reload button must be available.
65 Leave the Reload button even if HAL support is present, since the user
66 may wish to control the list manually, or force a reload.
69 Reverse engineer date/time functions
70 ------------------------------------
71 The date/time calculations in src/time.cc:Message2Time() are still not
72 completely understood. There is an explanation of sorts in an email
73 from Brian Edginton on the mailing list, but there are odd constants, etc.
74 Need to understand it fully and document it.
76 Mail from Brian Edginton on the topic:
77 http://sourceforge.net/mailarchive/message.php?msg_id=200706291619.05854.edge%40edginton.net
80 An automated test suite
81 -----------------------
82 Testing Barry will be a challenge, since an actual device is required
83 for a large bulk of tests. Ideally, it should be easy for someone to
84 make a full backup of their device, donate it to science, and then
85 restore their settings and data, since not everyone has a pure device
88 Things that need automated testing:
90 - test all possible compile options (finished, see test/)
91 - test parsing of all supported records
92 - test building of all supported records
93 - test backup and restore, of random sets of databases, as well
94 as the "all databases" set
95 - test LDAP / LDIF conversions
96 - test test Boost serialization backups and restore
97 - make sure it is possible to create records with the same
98 SHA1 sums, purely programmatically
99 - test syncing of all fields, including international data / charsets
100 - test password support, and password safety catch (bad passwd X times)
101 - test modem functionality
103 Estimated time: open ended
107 Flesh out the Troubleshooting web doc
108 -------------------------------------
109 Every stumbling block that users run into should either be fixed
110 in the code or binary package, or documented in a Troubleshooting
111 document. This troubleshooting document is already started, but
112 contributions are welcome from all users!
116 Timezone support to opensync plugins
117 ------------------------------------
118 Support for timezones will likely stress the opensync API as well as
119 the Barry API, but definitely needs to be done for completeness on both
120 sides of the equation.
122 This may involve switching from the text based vcard formats to
123 the opensync XML formats.
125 Estimated time: open ended
129 Multi-program Database and Modem Access
130 ---------------------------------------
131 The architectural challenge:
133 As Barry is not a single application, how do you access the
134 database while pppob is using the modem?
136 There are two viable ways of dealing with this. One involves placing
137 a (hopefully thin) driver in the kernel, and the other involves using
138 a daemon and RPC calls.
140 My preference is to implement this using RPC calls if needed, and hammer
141 out all the implementation details in user space. Once they are well
142 understood, a smaller kernel driver hook may be more easily written
143 that supports routing messages according to socket or application
144 needs. For example, one application may register an interest in
145 database messages, another in javaloader messages, and another in the
146 multiple modem socket messages.
148 There is currently no support for this RPC daemon, but threading
149 support already exists.
152 - design suitable RPC system
153 - implement support in the Barry library so it works
154 with and without a daemon, using the same API
155 Estimated time: open ended
159 Add bluetooth serial support
160 ----------------------------
161 It is reported that it is possible to access the database through
162 Bluetooth using the older Blackberry serial protocol. XmBlackBerry
163 has support for this and may be used as a reference.
165 The goal here would be to hide the bluetooth access behind the
166 same Barry library API, so that syncing with the opensync plugin
167 would be seamless whether plugged in via USB or Bluetooth.
170 - research and design serial protocol stack to reuse as much
171 library code as possible
172 Estimated time: unknown
176 Document the USB protocol
177 -------------------------
178 Currently the only english documentation for the Blackberry protocol
179 is the webpage by the Cassis project (found at
180 http://off.net/cassis/protocol-description.html).
182 The USB protocol is not nearly so well documented. The best documentation
183 available can be found in the Barry header files: protocol.h and
186 Translating the code into documentation (into a wiki, that will hopefully
187 soon be available) is a great way to get involved in the project and
188 learn a lot about the Blackberry from a low level.
190 Unfortunately, Jedi mind tricks don't often work when trying to convince
191 people to write documentation for me... :-)
194 - write, write, write
195 Estimated time: 40 hours (documentation expands to fill available time...)
201 Code can always be improved. There are two big ways to help:
203 - write an application using the Barry library
204 - improve the Barry library itself and send patches
206 By writing an application, you can provide crucial feedback on the ease
207 of use of the Barry API. I'm very eager for such feedback.
209 Secondly, there is currently a lot of code ducplication in the record
210 classes, and a careful refactoring is required. I would be open to a class
211 hierarchy, with possibly private or protected inheritance. My primary
212 concern is object safety when using the record classes as objects in
213 STL containers, with a secondary concern to make it easier to
214 abstractly work with a record. This implies a careful mix of
215 virtual functions and a generic record base class. Patches in this
216 area will be thoughtfully considered.
218 Estimated tasks (refactoring):
219 - design safe hierarchy
220 - move common code to base class
221 - make sure all record classes use the common record API
223 Estimated time: 7 hours
229 For those that write applications in C, a C API wrapper has been started
230 in the cbarry.h header. It has not yet been implemented, but should be
234 - finish some API design work (head not fully complete)
235 - implement all functions (about 50)
236 - write test application, or test suite, for C API
237 Estimated time: unknown
241 Python wrappers and example code
242 --------------------------------
243 For those that write applications in Python, a SWIG wrapper has been
244 started by H Miz Jones. This is partially functional, and involves
245 working with the Barry API, and may introduce changes to it depending
246 how hard it is to translate things to the Python world.
248 The SWIG wrapper scripts have not yet been publically released, but
249 please contact me if you are interested.
252 - finish C++ / Python integration (possible template issues)
253 - finish SWIG wrapper
254 Estimated time: unknown
259 ==============================================================================
263 Some distros release very early, and it is possible to follow
264 along their development cycle. These distros include Fedora,
265 Ubuntu, and Debian. There have already been some people reporting
266 bugs on pre-release versions of distros, and that has been very
267 helpful in ironing out kernel bugs, etc.
269 To help, build and test the latest stable and git Barry on
270 whatever distros you have available, and report bugs to the
276 If you have access to cutting edge GCC versions, please submit any
277 compiler issues you find to the mailing list.
282 You can help by periodically reviewing the web docs or
283 man pages, and submit patches or correction notes to the mailing
289 Ideally, downstream distro bugs are handled by the individual
290 package maintainers, but any bugs that are too hard to solve at
291 the distro level should be passed along upstream. I follow the
292 Debian package bugs, but other distros could use some help.
294 Also, for distro package maintainers, if you have a patch you
295 apply regularly to Barry, and if it can be incorporated into
296 upstream Barry, please send your patch to me via the mailing list.
297 I'd like to keep Barry as up-to-date with such fixes as possible.
302 To help here, test every feature on new Blackberry models and
303 official desktop software, and report what can be done with them
304 that you can't do on the previous model.
306 There should be a document listing all these features so
307 we know what to test against. We can add these features to this
308 TODO file, or start a new file under doc/ if you like.
313 There are many web support forums out there, where end users
314 discuss software and techniques. Unfortunately, I am unable to
315 follow all these forums, looking for Barry and BlackBerry handheld
316 related posts. But if you are a member of such a forum, you can
317 help Barry by responding to such topics, and if appropriate,
318 forwarding a link to the mailing list, so bugs can be fixed.
323 Upstream distros tend to change how they do things, or change their
324 official policies from time to time. If you are a distro user
325 who keeps up to date with these changes, you can help by
326 reporting if Barry's binary packaging or software is doing
327 something that is out of date or deprecated. Even better, please
328 document how it should be done instead.