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