| blob | ff5d0b77c4b4e1e031e8fb4b7a4ebafde956197a |
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.
8 - Chris
9 <cdfrey@foursquare.net>
12 Next Release Checklist (- todo, + done, x skipped)
13 ==============================================================================
14 Target: release version 0.16 (Oct 1)
15 + incorporate barrybackup GUI changes by Ryan Li
16 - incorporate Nicolas's java debugger patches
17 - figure out a solution to the HideSequencePacket issue
18 - fix any lingering compile problems and FIXMEs
19 - man page for bjdwp app
20 - www documentation for bjdwp app
21 - add bjdwp to debian and rpm binary packages
22 - incorporate Martin Owens' Barry logo/icon into Barry
23 - connect icon with barrybackup
24 - add to documentation page?
25 - add to identi.ca barry group
26 - add to sourceforge
27 - add to repo.or.cz
29 Target: release version 0.17 (Nov 1)
30 - website documentation:
31 - add a more detailed set of instructions for how to
32 contribute to the project using git
33 (see email to Josh)
34 - incorporate Bill Paul's modem HOWTO for FreeBSD
35 into web docs (see list emails)
36 - add docs for opensync 0.4x plugin (note that it is
37 currently experimental, based on devel opensync)
39 Target: release version 0.18 (Dec 1)
40 - test and fix all build and functionality issues on:
41 - Fedora 11
42 - Fedora 12 (scheduled release on Nov 10)
43 - Ubuntu 8.10, 9.04
44 - Ubuntu 9.10 (scheduled release on Oct 29)
45 - openSUSE 11.1
46 - see mailing list reports
47 - give openBSD a test compile
48 - support our own repositories for apt and yum and zypper
49 to make installation easier
51 Target: release version 0.19 (Jan 1, 2010)
52 - polish up bfuse, and add feature to split out fields
53 - add record classes for Content Store based on
54 Martin Owens' doc/barry-research.ods
55 - look at incorporating contrib/ into main tree, or at least
56 into binary packages and tests
61 General Features
62 ==============================================================================
64 Add firmware upgrade support via USB
65 ------------------------------------
66 Duplicate the firmware upgrade functionality of the RIM Windows
67 software. There are USB captures of this in the USB Capture Log
68 archive at http://www.netdirect.ca/software/packages/barry/logs.php
71 Add media management via USB
72 ----------------------------
73 The Windows version of desktop software has the ability to manage
74 photos on the Blackberry that are not stored on a flash card, but
75 are instead stored in the Blackberry's internal memory.
77 It is challenging, on some devices, to even copy such photos and
78 media to the flash card.
80 Capture the USB traffic for this media management, and add support
81 to Barry.
84 Add HAL/dbus support to BarryBackup
85 -----------------------------------
86 The latest version of the backup program lists devices in a combo box,
87 with a Reload button to handle new devices being plugged in.
89 Add an optional feature to listen to HAL/dbus for device addition and
90 removal and update the list automatically. Note that this must be
91 optional, since some systems may not have HAL available at compile time
92 (such as FreeBSD) or perhaps at runtime (HAL may not be running),
93 and so the Reload button must be available.
95 Leave the Reload button even if HAL support is present, since the user
96 may wish to control the list manually, or force a reload.
99 Command line tool to parse backups
100 ----------------------------------
101 Add the ability to feed raw database data into the parser from various
102 formats, so that you can test parser code, and get human readable output
103 without a Blackberry device attached.
105 Ideally, this tool should be able to read tarball backups from barrybackup,
106 and read only the database(s) of interest. There should be a sort of
107 plugin method for reading data from multiple sources: Windows backup
108 files, barrybackup files, btool save files, ldap, text, etc.
111 Add support for the new " - All" databases
112 ------------------------------------------
113 New Blackberry devices appear to support a set of mixed databases, such as
114 Calendar, Calendar - All, etc. The format of these new "All" databases
115 is not yet fully known, but needs to be supported as these databases become
116 more popular.
119 Reverse engineer date/time functions
120 ------------------------------------
121 The date/time calculations in src/time.cc:Message2Time() are still not
122 completely understood. There is an explanation of sorts in an email
123 from Brian Edginton on the mailing list, but there are odd constants, etc.
124 Need to understand it fully and document it.
126 Mail from Brian Edginton on the topic:
127 http://sourceforge.net/mailarchive/message.php?msg_id=200706291619.05854.edge%40edginton.net
130 Fix GUI configure script to run a check for libtar
131 --------------------------------------------------
132 Currently, the autoconf scripts only take an argument on the command line
133 for the location of libtar, and assumes its location otherwise.
134 There should be an actual test for this, that tries linking against
135 libtar, and stops the configure script if not available.
138 An automated test suite
139 -----------------------
140 Testing Barry will be a challenge, since an actual device is required
141 for a large bulk of tests. Ideally, it should be easy for someone to
142 make a full backup of their device, donate it to science, and then
143 restore their settings and data, since not everyone has a pure device
144 for testing.
146 Things that need automated testing:
148 - test all possible compile options (finished, see test/)
149 - test parsing of all supported records
150 - test building of all supported records
151 - test backup and restore, of random sets of databases, as well
152 as the "all databases" set
153 - test LDAP / LDIF conversions
154 - test test Boost serialization backups and restore
155 - make sure it is possible to create records with the same
156 SHA1 sums, purely programmatically
157 - test syncing of all fields, including international data / charsets
158 - test password support, and password safety catch (bad passwd X times)
159 - test modem functionality
161 Estimated time: open ended
165 Flesh out the Troubleshooting web doc
166 -------------------------------------
167 Every stumbling block that users run into should either be fixed
168 in the code or binary package, or documented in a Troubleshooting
169 document. This troubleshooting document is already started, but
170 contributions are welcome from all users!
174 Porting opensync plugin to opensync 0.40
175 ----------------------------------------
176 The main porting effort is mostly complete (pending changes in the
177 opensync API once the official 0.40 is released).
179 The XML way involves:
181 - switching from the vcard/vevent formats to the opensync XML
182 formats
183 - making use of the new opensync time APIs to properly support
184 timezones for all time operations
186 Switching away from text based vcard and vevent formats will remove
187 the burden of raw data parsing and formatting from the plugin itself,
188 and make use of the more tested opensync library. Any bugs fixed
189 in opensync's parsers will automatically fix bugs in the Barry plugin.
191 Support for timezones will likely stress the opensync API as well as
192 the Barry API, but definitely needs to be done for completeness on both
193 sides of the equation.
195 Estimated time: open ended
199 Adding support for recurring calendar items to opensync plugin
200 --------------------------------------------------------------
201 See vCalendar::RecurToBarryCal() in the opensync sources, and compare
202 with RecurToVCal(). See also iCal format RFC's.
203 http://tools.ietf.org/html/rfc2445
207 Multi-program Database and Modem Access
208 ---------------------------------------
209 The architectural challenge:
211 As Barry is not a single application, how do you access the
212 database while pppob is using the modem?
214 There are two viable ways of dealing with this. One involves placing
215 a (hopefully thin) driver in the kernel, and the other involves using
216 a daemon and RPC calls.
218 My preference is to implement this using RPC calls if needed, and hammer
219 out all the implementation details in user space. Once they are well
220 understood, a smaller kernel driver hook may be more easily written
221 that supports routing messages according to socket or application
222 needs. For example, one application may register an interest in
223 database messages, another in javaloader messages, and another in the
224 multiple modem socket messages.
226 There is currently no support for this RPC daemon, but threading
227 support already exists.
229 Estimated tasks:
230 - design suitable RPC system
231 - implement support in the Barry library so it works
232 with and without a daemon, using the same API
233 Estimated time: open ended
237 Add bluetooth serial support
238 ----------------------------
239 It is reported that it is possible to access the database through
240 Bluetooth using the older Blackberry serial protocol. XmBlackBerry
241 has support for this and may be used as a reference.
243 The goal here would be to hide the bluetooth access behind the
244 same Barry library API, so that syncing with the opensync plugin
245 would be seamless whether plugged in via USB or Bluetooth.
247 Estimated tasks:
248 - research and design serial protocol stack to reuse as much
249 library code as possible
250 Estimated time: unknown
254 Add internationalization (i18n) support to the backup GUI and tools
255 -------------------------------------------------------------------
256 Translations are needed for the GUI and command line tool prompts, as
257 well as support in the code for this translation.
259 Estimated tasks:
260 - update the code to support i18n
261 - translate to languages of interest
263 Estimated time: unknown
267 Write simple GUI for streamlining sync setup and action
268 -------------------------------------------------------
269 Syncing setup and operation is currently a tedious, complicated task.
270 A GUI that performed all the detailed setup and configuration work,
271 for a Blackberry-specific sync, using opensync libraries and plugins
272 for Evolution, Sunbird, etc, would be very helpful.
274 This would be much easier for an experienced GUI programmer, but there is
275 a learning curve for the opensync API.
277 Estimated tasks:
278 - document the settings required for Blackberry, and
279 all intended plugins required
280 - write application that:
281 - does the opensync configuration through the opensync
282 API directly
283 - scans the USB bus for available Blackberry devices using
284 Barry
285 - lives in the system tray watching for Blackberry devices
286 - if aiming for super ease of use, script a source build of
287 all needed opensync components and install in private
288 area to avoid conflict with system
289 Estimated time: unknown
290 Note: Depending how fast HAL, OpenSync, and Conduit are implemented,
291 this may never be needed... but if it existed today, there's a
292 lot of users who would be very happy...
296 Document the USB protocol
297 -------------------------
298 Currently the only english documentation for the Blackberry protocol
299 is the webpage by the Cassis project (found at
300 http://off.net/cassis/protocol-description.html).
302 The USB protocol is not nearly so well documented. The best documentation
303 available can be found in the Barry header files: protocol.h and
304 protostructs.h.
306 Translating the code into documentation (into a wiki, that will hopefully
307 soon be available) is a great way to get involved in the project and
308 learn a lot about the Blackberry from a low level.
310 Unfortunately, Jedi mind tricks don't often work when trying to convince
311 people to write documentation for me... :-)
313 Estimated tasks:
314 - write, write, write
315 Estimated time: 40 hours (documentation expands to fill available time...)
319 Code cleanup
320 ------------
321 Code can always be improved. There are two big ways to help:
323 - write an application using the Barry library
324 - improve the Barry library itself and send patches
326 By writing an application, you can provide crucial feedback on the ease
327 of use of the Barry API. I'm very eager for such feedback.
329 Secondly, there is currently a lot of code ducplication in the record
330 classes, and a careful refactoring is required. I would be open to a class
331 hierarchy, with possibly private or protected inheritance. My primary
332 concern is object safety when using the record classes as objects in
333 STL containers, with a secondary concern to make it easier to
334 abstractly work with a record. This implies a careful mix of
335 virtual functions and a generic record base class. Patches in this
336 area will be thoughtfully considered.
338 Estimated tasks (refactoring):
339 - design safe hierarchy
340 - move common code to base class
341 - make sure all record classes use the common record API
342 - test
343 Estimated time: 7 hours
347 C API wrapper
348 -------------
349 For those that write applications in C, a C API wrapper has been started
350 in the cbarry.h header. It has not yet been implemented, but should be
351 straightforward.
353 Estimated tasks:
354 - finish some API design work (head not fully complete)
355 - implement all functions (about 50)
356 - write test application, or test suite, for C API
357 Estimated time: unknown
361 Python wrappers and example code
362 --------------------------------
363 For those that write applications in Python, a SWIG wrapper has been
364 started by H Miz Jones. This is partially functional, and involves
365 working with the Barry API, and may introduce changes to it depending
366 how hard it is to translate things to the Python world.
368 The SWIG wrapper scripts have not yet been publically released, but
369 please contact me if you are interested.
371 Estimated tasks:
372 - finish C++ / Python integration (possible template issues)
373 - finish SWIG wrapper
374 Estimated time: unknown
378 Command line backup and restore
379 -------------------------------
380 The only command line backup currently available is the one in btool,
381 using the -f and -s switches. This does not backup exact data from
382 the device, but parses it, stores it in the Boost serialization format,
383 and then reverses the process for restore. This is a great test
384 for the Barry library, but not so great for backup, since not all
385 databases can be parsed.
387 There is already an exact backup and restore interface with the GUI, but
388 there is a lot of useful functionality trapped in a layer of GUI
389 that could be just as useful from the command line. Tasks such as a nightly
390 cron backup of any Blackberry devices attached to the system would be more
391 easily done via command line.
393 You could add command line arguments to the barrybackup program to skip
394 the GUI (tricky and possibly error prone), or you could pull the backup
395 functionality into a standalone command line utility (more work, but smarter
396 in the long run). This is mostly a code refactoring job, consisting of
397 all working code that's already there, and I know there are people
398 who would thank you. :-)
400 Note: see also the perl scripts in contrib/
402 Estimated tasks:
403 - split out tar and backup functionality code into shared library
404 - write and test command line tool
405 Estimated time: 6 hours
409 Misc Low Level Todo Items:
410 --------------------------
411 - test whether sorting of contact records is required before
412 uploading data to the device... test whether it is ok
413 to upload a GroupLink item in the middle of a contact
414 upload, even before all the groups have been sent...
415 if ok, remove the sorting code from Contact, Message, and
416 Calendar classes