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