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