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