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