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.
9 <cdfrey@foursquare.net>
12 Next Release Checklist (- todo, + done, x skipped)
13 ==============================================================================
14 Target: release version 0.15
15 - finish javaloader support, implementing all known commands
21 - is there a way to delete COD files too?
22 - polish up bfuse, and add feature to split out fields
23 - add record classes for Content Store, SMS Messages, based on
24 Martin Owens' doc/barry-research.ods
25 - test and fix all build and functionality issues on:
28 - Debian lenny and unstable
29 - see sknauert's email
31 - see mailing list reports
32 - give openBSD a test compile
33 - catchup on sourceforge tracker items
34 - incorporate Bill Paul's modem HOWTO for FreeBSD into web docs
36 - review all website documentation before release
37 - make sure all manpages are up to date, including bjavaloader
39 Target: release version 0.16
40 - port opensync plugin to 0.4x
46 ==============================================================================
48 Add support for the Blackberry Storm
49 ------------------------------------
50 The new Blackberry Storm, model 9530, appears to have a different database
51 protocol. This will likely be an ongoing effort to add support for this
52 device, or at least find a way to use the old protocol with it.
54 Search the mailing list archives for "Storm" or "9530".
57 Look into password support in the OpenSync framework
58 ----------------------------------------------------
59 Currently, if a Blackberry uses a password, in order to sync it,
60 you need to store the password in plaintext in the sync configuration.
61 This is less than ideal.
63 Ideally, opensync should prompt for the password, so that this is a
64 part of the user interface. Someone needs to research OpenSync, and if
65 there is support for passwords in the plugin API, implement it for Barry
68 Reverse engineer date/time functions
69 ------------------------------------
70 The date/time calculations in src/time.cc:Message2Time() are still not
71 completely understood. There is an explanation of sorts in an email
72 from Brian Edginton on the mailing list, but there are odd constants, etc.
73 Need to understand it fully and document it.
75 Mail from Brian Edginton on the topic:
76 http://sourceforge.net/mailarchive/message.php?msg_id=200706291619.05854.edge%40edginton.net
79 Fix GUI configure script to run a check for libtar
80 --------------------------------------------------
81 Currently, the autoconf scripts only take an argument on the command line
82 for the location of libtar, and assumes its location otherwise.
83 There should be an actual test for this, that tries linking against
84 libtar, and stops the configure script if not available.
87 An automated test suite
88 -----------------------
89 Testing Barry will be a challenge, since an actual device is required
90 for a large bulk of tests. Ideally, it should be easy for someone to
91 make a full backup of their device, donate it to science, and then
92 restore their settings and data, since not everyone has a pure device
95 Things that need automated testing:
97 - test all possible compile options (finished, see test/)
98 - test parsing of all supported records
99 - test building of all supported records
100 - test backup and restore, of random sets of databases, as well
101 as the "all databases" set
102 - test LDAP / LDIF conversions
103 - test test Boost serialization backups and restore
104 - make sure it is possible to create records with the same
105 SHA1 sums, purely programmatically
106 - test syncing of all fields, including international data / charsets
107 - test password support, and password safety catch (bad passwd X times)
108 - test modem functionality
110 Estimated time: open ended
114 Flesh out the Troubleshooting web doc
115 -------------------------------------
116 Every stumbling block that users run into should either be fixed
117 in the code or binary package, or documented in a Troubleshooting
118 document. This troubleshooting document is already started, but
119 contributions are welcome from all users!
123 Porting opensync plugin to opensync 0.40
124 ----------------------------------------
125 There's two options to this item:
130 The difference between opensync 0.22 and 0.40 involves some API changes.
131 You should be able to note the changes in the example plugin code once
134 The simple way involves merely updating Barry's opensync plugin to match
135 the new API. This shouldn't be too difficult, but you may run across
136 some small surprises.
138 The proper way involves:
140 - switching from the vcard/vevent formats to the opensync XML
142 - switching from storing state information in text files to
143 storing it in the built in database (optional)
144 - making use of the new opensync time APIs to properly support
145 timezones for all time operations
147 Switching away from text based vcard and vevent formats will remove
148 the burden of raw data parsing and formatting from the plugin itself,
149 and make use of the more tested opensync library. Any bugs fixed
150 in opensync's parsers will automatically fix bugs in the Barry plugin.
152 Switching state storage formats may allow for greater flexibility
153 in supporting multiple devices. This needs more research, but it
154 is the "way things are done" in opensync, and likely worth moving
157 Support for timezones will likely stress the opensync API as well as
158 the Barry API, but definitely needs to be done for completeness on both
159 sides of the equation.
161 Estimated time: simple way: 10 hours if lucky
162 proper way: open ended
166 Adding support for Tasks database to opensync plugin
167 ----------------------------------------------------
168 This will require research into the proper vformat for tasks. If
169 the above port to 0.40 is complete, then use the XML format. If not,
170 then find the appropriate v-format.
172 Estimated time: 16 hours
173 Depending on: ideally, wait for 0.40 XML format support
177 Adding support for Memos (notes) to opensync plugin
178 ---------------------------------------------------
179 Same as above, for Tasks. If done together, may be able to save some time.
181 Estimated time: 16 hours
182 Depending on: ideally, wait for 0.40 XML format support
186 Adding support for recurring calendar items to opensync plugin
187 --------------------------------------------------------------
188 See vCalendar::RecurToBarryCal() in the opensync sources, and compare
189 with RecurToVCal(). See also iCal format RFC's.
190 http://tools.ietf.org/html/rfc2445
194 Reverse engineering java loader protocol
195 ----------------------------------------
196 This has not been done by any opensource Blackberry project out there,
197 to my knowledge, and would be most useful to Blackberry application
200 If you are a Blackberry app developer, this may interest you.
202 Estimated time: open ended
206 Multi-program Database and Modem Access
207 ---------------------------------------
208 The architectural challenge:
210 As Barry is not a single application, how do you access the
211 database while pppob is using the modem?
213 There are two viable ways of dealing with this. One involves placing
214 a (hopefully thin) driver in the kernel, and the other involves using
215 a daemon and RPC calls.
217 My preference is to implement this using RPC calls if needed, and hammer
218 out all the implementation details in user space. Once they are well
219 understood, a smaller kernel driver hook may be more easily written
220 that supports routing messages according to socket or application
221 needs. For example, one application may register an interest in
222 database messages, another in javaloader messages, and another in the
223 multiple modem socket messages.
225 There is currently no support for this RPC daemon, but threading
226 support already exists.
229 - design suitable RPC system
230 - implement support in the Barry library so it works
231 with and without a daemon, using the same API
232 Estimated time: open ended
236 Add bluetooth serial support
237 ----------------------------
238 It is reported that it is possible to access the database through
239 Bluetooth using the older Blackberry serial protocol. XmBlackBerry
240 has support for this and may be used as a reference.
242 The goal here would be to hide the bluetooth access behind the
243 same Barry library API, so that syncing with the opensync plugin
244 would be seamless whether plugged in via USB or Bluetooth.
247 - research and design serial protocol stack to reuse as much
248 library code as possible
249 Estimated time: unknown
253 Add internationalization (i18n) support to the backup GUI and tools
254 -------------------------------------------------------------------
255 Translations are needed for the GUI and command line tool prompts, as
256 well as support in the code for this translation.
259 - update the code to support i18n
260 - translate to languages of interest
262 Estimated time: unknown
266 Write simple GUI for streamlining sync setup and action
267 -------------------------------------------------------
268 Syncing setup and operation is currently a tedious, complicated task.
269 A GUI that performed all the detailed setup and configuration work,
270 for a Blackberry-specific sync, using opensync libraries and plugins
271 for Evolution, Sunbird, etc, would be very helpful.
273 This would be much easier for an experienced GUI programmer, but there is
274 a learning curve for the opensync API.
277 - document the settings required for Blackberry, and
278 all intended plugins required
279 - write application that:
280 - does the opensync configuration through the opensync
282 - scans the USB bus for available Blackberry devices using
284 - lives in the system tray watching for Blackberry devices
285 - if aiming for super ease of use, script a source build of
286 all needed opensync components and install in private
287 area to avoid conflict with system
288 Estimated time: unknown
289 Note: Depending how fast HAL, OpenSync, and Conduit are implemented,
290 this may never be needed... but if it existed today, there's a
291 lot of users who would be very happy...
295 Document the USB protocol
296 -------------------------
297 Currently the only english documentation for the Blackberry protocol
298 is the webpage by the Cassis project (found at
299 http://off.net/cassis/protocol-description.html).
301 The USB protocol is not nearly so well documented. The best documentation
302 available can be found in the Barry header files: protocol.h and
305 Translating the code into documentation (into a wiki, that will hopefully
306 soon be available) is a great way to get involved in the project and
307 learn a lot about the Blackberry from a low level.
309 Unfortunately, Jedi mind tricks don't often work when trying to convince
310 people to write documentation for me... :-)
313 - write, write, write
314 Estimated time: 40 hours (documentation expands to fill available time...)
320 Code can always be improved. There are two big ways to help:
322 - write an application using the Barry library
323 - improve the Barry library itself and send patches
325 By writing an application, you can provide crucial feedback on the ease
326 of use of the Barry API. I'm very eager for such feedback.
328 Secondly, there is currently a lot of code ducplication in the record
329 classes, and a careful refactoring is required. I would be open to a class
330 hierarchy, with possibly private or protected inheritance. My primary
331 concern is object safety when using the record classes as objects in
332 STL containers, with a secondary concern to make it easier to
333 abstractly work with a record. This implies a careful mix of
334 virtual functions and a generic record base class. Patches in this
335 area will be thoughtfully considered.
337 Estimated tasks (refactoring):
338 - design safe hierarchy
339 - move common code to base class
340 - make sure all record classes use the common record API
342 Estimated time: 7 hours
348 For those that write applications in C, a C API wrapper has been started
349 in the cbarry.h header. It has not yet been implemented, but should be
353 - finish some API design work (head not fully complete)
354 - implement all functions (about 50)
355 - write test application, or test suite, for C API
356 Estimated time: unknown
360 Python wrappers and example code
361 --------------------------------
362 For those that write applications in Python, a SWIG wrapper has been
363 started by H Miz Jones. This is partially functional, and involves
364 working with the Barry API, and may introduce changes to it depending
365 how hard it is to translate things to the Python world.
367 The SWIG wrapper scripts have not yet been publically released, but
368 please contact me if you are interested.
371 - finish C++ / Python integration (possible template issues)
372 - finish SWIG wrapper
373 Estimated time: unknown
377 Command line backup and restore
378 -------------------------------
379 The only command line backup currently available is the one in btool,
380 using the -f and -s switches. This does not backup exact data from
381 the device, but parses it, stores it in the Boost serialization format,
382 and then reverses the process for restore. This is a great test
383 for the Barry library, but not so great for backup, since not all
384 databases can be parsed.
386 There is already an exact backup and restore interface with the GUI, but
387 there is a lot of useful functionality trapped in a layer of GUI
388 that could be just as useful from the command line. Tasks such as a nightly
389 cron backup of any Blackberry devices attached to the system would be more
390 easily done via command line.
392 You could add command line arguments to the barrybackup program to skip
393 the GUI (tricky and possibly error prone), or you could pull the backup
394 functionality into a standalone command line utility (more work, but smarter
395 in the long run). This is mostly a code refactoring job, consisting of
396 all working code that's already there, and I know there are people
397 who would thank you. :-)
399 Note: see also the perl scripts in contrib/
402 - split out tar and backup functionality code into shared library
403 - write and test command line tool
404 Estimated time: 6 hours
408 Misc Low Level Todo Items:
409 --------------------------
410 - test whether sorting of contact records is required before
411 uploading data to the device... test whether it is ok
412 to upload a GroupLink item in the middle of a contact
413 upload, even before all the groups have been sent...
414 if ok, remove the sorting code from Contact, Message, and