TODO

   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.
   4
   5 If you would like help or more information on any of these items,
   6 please ask on the mailing list as well.
   7
   8 - Chris
   9 <cdfrey@foursquare.net>
  10
  11
  12 Next Release Checklist (- todo, + done, x skipped)
  13 ==============================================================================
  14 Target: release version 0.15
  15         - finish javaloader support, implementing all known commands
  16                 + write COD to device
  17                 + list
  18                 + save
  19                 + set time
  20                 + device-info
  21                 + screenshot
  22                 + delete COD files (javaloader erase)
  23         - test and fix all build and functionality issues on:
  24                 - Fedora 10
  25                 - Ubuntu 8.10
  26                 - Debian lenny
  27                 - openSUSE 11.1
  28                         - see mailing list reports
  29                 - give openBSD a test compile
  30         - catchup on sourceforge tracker items
  31         - incorporate Bill Paul's modem HOWTO for FreeBSD into web docs
  32                 (see list emails)
  33         - review all website documentation before release
  34                 - add a more detailed set of instructions for how to
  35                         contribute to the project using git
  36                         (see email to Josh)
  37         + make sure all manpages are up to date, including bjavaloader
  38         - include Nicolas's opensync plugin 0.4x branch
  39                 - update website documentation to indicate this is
  40                         an experimental plugin, since the main opensync
  41                         framework is not released yet
  42
  43 Target: release version 0.16
  44         - polish up bfuse, and add feature to split out fields
  45         - add record classes for Content Store, SMS Messages, based on
  46                 Martin Owens' doc/barry-research.ods
  47
  48
  49
  50
  51 General Features
  52 ==============================================================================
  53
  54 Add support for the new " - All" databases
  55 ------------------------------------------
  56 New Blackberry devices appear to support a set of mixed databases, such as
  57 Calendar, Calendar - All, etc.  The format of these new "All" databases
  58 is not yet fully known, but needs to be supported as these databases become
  59 more popular.
  60
  61
  62 Add support for the Blackberry Storm
  63 ------------------------------------
  64 The new Blackberry Storm, model 9530, appears to have a different database
  65 protocol.  This will likely be an ongoing effort to add support for this
  66 device, or at least find a way to use the old protocol with it.
  67
  68 Search the mailing list archives for "Storm" or "9530".
  69
  70
  71 Look into password support in the OpenSync framework
  72 ----------------------------------------------------
  73 Currently, if a Blackberry uses a password, in order to sync it,
  74 you need to store the password in plaintext in the sync configuration.
  75 This is less than ideal.
  76
  77 Ideally, opensync should prompt for the password, so that this is a
  78 part of the user interface.  Someone needs to research OpenSync, and if
  79 there is support for passwords in the plugin API, implement it for Barry
  80
  81
  82 Reverse engineer date/time functions
  83 ------------------------------------
  84 The date/time calculations in src/time.cc:Message2Time() are still not
  85 completely understood.  There is an explanation of sorts in an email
  86 from Brian Edginton on the mailing list, but there are odd constants, etc.
  87 Need to understand it fully and document it.
  88
  89 Mail from Brian Edginton on the topic:
  90 http://sourceforge.net/mailarchive/message.php?msg_id=200706291619.05854.edge%40edginton.net
  91
  92
  93 Fix GUI configure script to run a check for libtar
  94 --------------------------------------------------
  95 Currently, the autoconf scripts only take an argument on the command line
  96 for the location of libtar, and assumes its location otherwise.
  97 There should be an actual test for this, that tries linking against
  98 libtar, and stops the configure script if not available.
  99
 100
 101 An automated test suite
 102 -----------------------
 103 Testing Barry will be a challenge, since an actual device is required
 104 for a large bulk of tests.  Ideally, it should be easy for someone to
 105 make a full backup of their device, donate it to science, and then
 106 restore their settings and data, since not everyone has a pure device
 107 for testing.
 108
 109 Things that need automated testing:
 110
 111         - test all possible compile options (finished, see test/)
 112         - test parsing of all supported records
 113         - test building of all supported records
 114         - test backup and restore, of random sets of databases, as well
 115                 as the "all databases" set
 116         - test LDAP / LDIF conversions
 117         - test test Boost serialization backups and restore
 118         - make sure it is possible to create records with the same
 119                 SHA1 sums, purely programmatically
 120         - test syncing of all fields, including international data / charsets
 121         - test password support, and password safety catch (bad passwd X times)
 122         - test modem functionality
 123
 124 Estimated time: open ended
 125
 126
 127
 128 Flesh out the Troubleshooting web doc
 129 -------------------------------------
 130 Every stumbling block that users run into should either be fixed
 131 in the code or binary package, or documented in a Troubleshooting
 132 document.  This troubleshooting document is already started, but
 133 contributions are welcome from all users!
 134
 135
 136
 137 Porting opensync plugin to opensync 0.40
 138 ----------------------------------------
 139 There's two options to this item:
 140
 141         - simple way
 142         - proper way
 143
 144 The difference between opensync 0.22 and 0.40 involves some API changes.
 145 You should be able to note the changes in the example plugin code once
 146 0.40 is released.
 147
 148 The simple way involves merely updating Barry's opensync plugin to match
 149 the new API.  This shouldn't be too difficult, but you may run across
 150 some small surprises.
 151
 152 The proper way involves:
 153
 154         - switching from the vcard/vevent formats to the opensync XML
 155                 formats
 156         - switching from storing state information in text files to
 157                 storing it in the built in database (optional)
 158         - making use of the new opensync time APIs to properly support
 159                 timezones for all time operations
 160
 161 Switching away from text based vcard and vevent formats will remove
 162 the burden of raw data parsing and formatting from the plugin itself,
 163 and make use of the more tested opensync library.  Any bugs fixed
 164 in opensync's parsers will automatically fix bugs in the Barry plugin.
 165
 166 Switching state storage formats may allow for greater flexibility
 167 in supporting multiple devices.  This needs more research, but it
 168 is the "way things are done" in opensync, and likely worth moving
 169 in that direction.
 170
 171 Support for timezones will likely stress the opensync API as well as
 172 the Barry API, but definitely needs to be done for completeness on both
 173 sides of the equation.
 174
 175 Estimated time:   simple way: 10 hours if lucky
 176                   proper way: open ended
 177
 178
 179
 180 Adding support for Tasks database to opensync plugin
 181 ----------------------------------------------------
 182 This will require research into the proper vformat for tasks.  If
 183 the above port to 0.40 is complete, then use the XML format.  If not,
 184 then find the appropriate v-format.
 185
 186 Estimated time: 16 hours
 187 Depending on: ideally, wait for 0.40 XML format support
 188
 189
 190
 191 Adding support for Memos (notes) to opensync plugin
 192 ---------------------------------------------------
 193 Same as above, for Tasks.  If done together, may be able to save some time.
 194
 195 Estimated time: 16 hours
 196 Depending on: ideally, wait for 0.40 XML format support
 197
 198
 199
 200 Adding support for recurring calendar items to opensync plugin
 201 --------------------------------------------------------------
 202 See vCalendar::RecurToBarryCal() in the opensync sources, and compare
 203 with RecurToVCal().  See also iCal format RFC's.
 204 http://tools.ietf.org/html/rfc2445
 205
 206
 207
 208 Multi-program Database and Modem Access
 209 ---------------------------------------
 210 The architectural challenge:
 211
 212         As Barry is not a single application, how do you access the
 213         database while pppob is using the modem?
 214
 215 There are two viable ways of dealing with this.  One involves placing
 216 a (hopefully thin) driver in the kernel, and the other involves using
 217 a daemon and RPC calls.
 218
 219 My preference is to implement this using RPC calls if needed, and hammer
 220 out all the implementation details in user space.  Once they are well
 221 understood, a smaller kernel driver hook may be more easily written
 222 that supports routing messages according to socket or application
 223 needs.  For example, one application may register an interest in
 224 database messages, another in javaloader messages, and another in the
 225 multiple modem socket messages.
 226
 227 There is currently no support for this RPC daemon, but threading
 228 support already exists.
 229
 230 Estimated tasks:
 231         - design suitable RPC system
 232         - implement support in the Barry library so it works
 233                 with and without a daemon, using the same API
 234 Estimated time: open ended
 235
 236
 237
 238 Add bluetooth serial support
 239 ----------------------------
 240 It is reported that it is possible to access the database through
 241 Bluetooth using the older Blackberry serial protocol.  XmBlackBerry
 242 has support for this and may be used as a reference.
 243
 244 The goal here would be to hide the bluetooth access behind the
 245 same Barry library API, so that syncing with the opensync plugin
 246 would be seamless whether plugged in via USB or Bluetooth.
 247
 248 Estimated tasks:
 249         - research and design serial protocol stack to reuse as much
 250                 library code as possible
 251 Estimated time: unknown
 252
 253
 254
 255 Add internationalization (i18n) support to the backup GUI and tools
 256 -------------------------------------------------------------------
 257 Translations are needed for the GUI and command line tool prompts, as
 258 well as support in the code for this translation.
 259
 260 Estimated tasks:
 261         - update the code to support i18n
 262         - translate to languages of interest
 263
 264 Estimated time: unknown
 265
 266
 267
 268 Write simple GUI for streamlining sync setup and action
 269 -------------------------------------------------------
 270 Syncing setup and operation is currently a tedious, complicated task.
 271 A GUI that performed all the detailed setup and configuration work,
 272 for a Blackberry-specific sync, using opensync libraries and plugins
 273 for Evolution, Sunbird, etc, would be very helpful.
 274
 275 This would be much easier for an experienced GUI programmer, but there is
 276 a learning curve for the opensync API.
 277
 278 Estimated tasks:
 279         - document the settings required for Blackberry, and
 280                 all intended plugins required
 281         - write application that:
 282                 - does the opensync configuration through the opensync
 283                         API directly
 284                 - scans the USB bus for available Blackberry devices using
 285                         Barry
 286                 - lives in the system tray watching for Blackberry devices
 287         - if aiming for super ease of use, script a source build of
 288                 all needed opensync components and install in private
 289                 area to avoid conflict with system
 290 Estimated time: unknown
 291 Note: Depending how fast HAL, OpenSync, and Conduit are implemented,
 292         this may never be needed... but if it existed today, there's a
 293         lot of users who would be very happy...
 294
 295
 296
 297 Document the USB protocol
 298 -------------------------
 299 Currently the only english documentation for the Blackberry protocol
 300 is the webpage by the Cassis project (found at
 301 http://off.net/cassis/protocol-description.html).
 302
 303 The USB protocol is not nearly so well documented.  The best documentation
 304 available can be found in the Barry header files: protocol.h and
 305 protostructs.h.
 306
 307 Translating the code into documentation (into a wiki, that will hopefully
 308 soon be available) is a great way to get involved in the project and
 309 learn a lot about the Blackberry from a low level.
 310
 311 Unfortunately, Jedi mind tricks don't often work when trying to convince
 312 people to write documentation for me... :-)
 313
 314 Estimated tasks:
 315         - write, write, write
 316 Estimated time: 40 hours (documentation expands to fill available time...)
 317
 318
 319
 320 Code cleanup
 321 ------------
 322 Code can always be improved.  There are two big ways to help:
 323
 324         - write an application using the Barry library
 325         - improve the Barry library itself and send patches
 326
 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.
 329
 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.
 338
 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
 345
 346
 347
 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.
 353
 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
 359
 360
 361
 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.
 368
 369 The SWIG wrapper scripts have not yet been publically released, but
 370 please contact me if you are interested.
 371
 372 Estimated tasks:
 373         - finish C++ / Python integration (possible template issues)
 374         - finish SWIG wrapper
 375 Estimated time: unknown
 376
 377
 378
 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.
 387
 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.
 393
 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. :-)
 400
 401 Note: see also the perl scripts in contrib/
 402
 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
 407
 408
 409
 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
 418