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