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