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 Next Release Checklist (- todo, + done, x skipped)
  13 ==============================================================================
  14 Target: release version 0.18
  15         - figure out a solution to the HideSequencePacket issue
  16         - website documentation:
  17                 - www documentation / howto for bjdwp and friends
  18                 - add a more detailed set of instructions for how to
  19                         contribute to the project using git
  20                         (see email to Josh)
  21                 - incorporate Bill Paul's modem HOWTO for FreeBSD
  22                         into web docs (see list emails)
  23                 - add docs for opensync 0.4x plugin (note that it is
  24                         currently experimental, based on devel opensync)
  25                 - add docs for using libmtp with the Storm to access media
  26         - incorporate Martin Owens' Barry logo/icon into Barry
  27                 - add to documentation page?
  28                 - add to identi.ca barry group
  29                 - add to sourceforge
  30                 - add to repo.or.cz
  31
  32 Target: release version 0.19
  33         - test and fix all build and functionality issues on:
  34                 - Fedora 11
  35                 - Fedora 12 (scheduled release on Nov 10)
  36                 - Ubuntu 8.10, 9.04
  37                 - Ubuntu 9.10 (scheduled release on Oct 29)
  38                 - openSUSE 11.1
  39                         - see mailing list reports
  40                 - give openBSD a test compile
  41         - support our own repositories for apt and yum and zypper
  42                 to make installation easier
  43
  44 Target: release version 0.20
  45         - polish up bfuse, and add feature to split out fields
  46         - add record classes for Content Store based on
  47                 Martin Owens' doc/barry-research.ods
  48         - look at incorporating contrib/ into main tree, or at least
  49                 into binary packages and tests
  50
  51
  52
  53
  54 General Features
  55 ==============================================================================
  56
  57 Add firmware upgrade support via USB
  58 ------------------------------------
  59 Duplicate the firmware upgrade functionality of the RIM Windows
  60 software.  There are USB captures of this in the USB Capture Log
  61 archive at http://www.netdirect.ca/software/packages/barry/logs.php
  62
  63
  64 Add media management via USB
  65 ----------------------------
  66 The Windows version of desktop software has the ability to manage
  67 photos on the Blackberry that are not stored on a flash card, but
  68 are instead stored in the Blackberry's internal memory.
  69
  70 It is challenging, on some devices, to even copy such photos and
  71 media to the flash card.
  72
  73 Capture the USB traffic for this media management, and add support
  74 to Barry.
  75
  76
  77 Add HAL/dbus support to BarryBackup
  78 -----------------------------------
  79 The latest version of the backup program lists devices in a combo box,
  80 with a Reload button to handle new devices being plugged in.
  81
  82 Add an optional feature to listen to HAL/dbus for device addition and
  83 removal and update the list automatically.  Note that this must be
  84 optional, since some systems may not have HAL available at compile time
  85 (such as FreeBSD) or perhaps at runtime (HAL may not be running),
  86 and so the Reload button must be available.
  87
  88 Leave the Reload button even if HAL support is present, since the user
  89 may wish to control the list manually, or force a reload.
  90
  91
  92 Reverse engineer date/time functions
  93 ------------------------------------
  94 The date/time calculations in src/time.cc:Message2Time() are still not
  95 completely understood.  There is an explanation of sorts in an email
  96 from Brian Edginton on the mailing list, but there are odd constants, etc.
  97 Need to understand it fully and document it.
  98
  99 Mail from Brian Edginton on the topic:
 100 http://sourceforge.net/mailarchive/message.php?msg_id=200706291619.05854.edge%40edginton.net
 101
 102
 103 An automated test suite
 104 -----------------------
 105 Testing Barry will be a challenge, since an actual device is required
 106 for a large bulk of tests.  Ideally, it should be easy for someone to
 107 make a full backup of their device, donate it to science, and then
 108 restore their settings and data, since not everyone has a pure device
 109 for testing.
 110
 111 Things that need automated testing:
 112
 113         - test all possible compile options (finished, see test/)
 114         - test parsing of all supported records
 115         - test building of all supported records
 116         - test backup and restore, of random sets of databases, as well
 117                 as the "all databases" set
 118         - test LDAP / LDIF conversions
 119         - test test Boost serialization backups and restore
 120         - make sure it is possible to create records with the same
 121                 SHA1 sums, purely programmatically
 122         - test syncing of all fields, including international data / charsets
 123         - test password support, and password safety catch (bad passwd X times)
 124         - test modem functionality
 125
 126 Estimated time: open ended
 127
 128
 129
 130 Flesh out the Troubleshooting web doc
 131 -------------------------------------
 132 Every stumbling block that users run into should either be fixed
 133 in the code or binary package, or documented in a Troubleshooting
 134 document.  This troubleshooting document is already started, but
 135 contributions are welcome from all users!
 136
 137
 138
 139 Timezone support to opensync plugins
 140 ------------------------------------
 141 Support for timezones will likely stress the opensync API as well as
 142 the Barry API, but definitely needs to be done for completeness on both
 143 sides of the equation.
 144
 145 This may involve switching from the text based vcard formats to
 146 the opensync XML formats.
 147
 148 Estimated time:   open ended
 149
 150
 151
 152 Multi-program Database and Modem Access
 153 ---------------------------------------
 154 The architectural challenge:
 155
 156         As Barry is not a single application, how do you access the
 157         database while pppob is using the modem?
 158
 159 There are two viable ways of dealing with this.  One involves placing
 160 a (hopefully thin) driver in the kernel, and the other involves using
 161 a daemon and RPC calls.
 162
 163 My preference is to implement this using RPC calls if needed, and hammer
 164 out all the implementation details in user space.  Once they are well
 165 understood, a smaller kernel driver hook may be more easily written
 166 that supports routing messages according to socket or application
 167 needs.  For example, one application may register an interest in
 168 database messages, another in javaloader messages, and another in the
 169 multiple modem socket messages.
 170
 171 There is currently no support for this RPC daemon, but threading
 172 support already exists.
 173
 174 Estimated tasks:
 175         - design suitable RPC system
 176         - implement support in the Barry library so it works
 177                 with and without a daemon, using the same API
 178 Estimated time: open ended
 179
 180
 181
 182 Add bluetooth serial support
 183 ----------------------------
 184 It is reported that it is possible to access the database through
 185 Bluetooth using the older Blackberry serial protocol.  XmBlackBerry
 186 has support for this and may be used as a reference.
 187
 188 The goal here would be to hide the bluetooth access behind the
 189 same Barry library API, so that syncing with the opensync plugin
 190 would be seamless whether plugged in via USB or Bluetooth.
 191
 192 Estimated tasks:
 193         - research and design serial protocol stack to reuse as much
 194                 library code as possible
 195 Estimated time: unknown
 196
 197
 198
 199 Write simple GUI for streamlining sync setup and action
 200 -------------------------------------------------------
 201 Syncing setup and operation is currently a tedious, complicated task.
 202 A GUI that performed all the detailed setup and configuration work,
 203 for a Blackberry-specific sync, using opensync libraries and plugins
 204 for Evolution, Sunbird, etc, would be very helpful.
 205
 206 This would be much easier for an experienced GUI programmer, but there is
 207 a learning curve for the opensync API.
 208
 209 Estimated tasks:
 210         - document the settings required for Blackberry, and
 211                 all intended plugins required
 212         - write application that:
 213                 - does the opensync configuration through the opensync
 214                         API directly
 215                 - scans the USB bus for available Blackberry devices using
 216                         Barry
 217                 - lives in the system tray watching for Blackberry devices
 218         - if aiming for super ease of use, script a source build of
 219                 all needed opensync components and install in private
 220                 area to avoid conflict with system
 221 Estimated time: unknown
 222 Note: Depending how fast HAL, OpenSync, and Conduit are implemented,
 223         this may never be needed... but if it existed today, there's a
 224         lot of users who would be very happy...
 225
 226
 227
 228 Document the USB protocol
 229 -------------------------
 230 Currently the only english documentation for the Blackberry protocol
 231 is the webpage by the Cassis project (found at
 232 http://off.net/cassis/protocol-description.html).
 233
 234 The USB protocol is not nearly so well documented.  The best documentation
 235 available can be found in the Barry header files: protocol.h and
 236 protostructs.h.
 237
 238 Translating the code into documentation (into a wiki, that will hopefully
 239 soon be available) is a great way to get involved in the project and
 240 learn a lot about the Blackberry from a low level.
 241
 242 Unfortunately, Jedi mind tricks don't often work when trying to convince
 243 people to write documentation for me... :-)
 244
 245 Estimated tasks:
 246         - write, write, write
 247 Estimated time: 40 hours (documentation expands to fill available time...)
 248
 249
 250
 251 Improve useability of web documentation
 252 ---------------------------------------
 253 Add a Q&A style of support web site, where Blackberry users can plug in
 254 their device model, data provider, etc. and get exact command lines that
 255 they can use for modem tethering, etc.
 256
 257
 258
 259 Code cleanup
 260 ------------
 261 Code can always be improved.  There are two big ways to help:
 262
 263         - write an application using the Barry library
 264         - improve the Barry library itself and send patches
 265
 266 By writing an application, you can provide crucial feedback on the ease
 267 of use of the Barry API.  I'm very eager for such feedback.
 268
 269 Secondly, there is currently a lot of code ducplication in the record
 270 classes, and a careful refactoring is required.  I would be open to a class
 271 hierarchy, with possibly private or protected inheritance.  My primary
 272 concern is object safety when using the record classes as objects in
 273 STL containers, with a secondary concern to make it easier to
 274 abstractly work with a record.  This implies a careful mix of
 275 virtual functions and a generic record base class.  Patches in this
 276 area will be thoughtfully considered.
 277
 278 Estimated tasks (refactoring):
 279         - design safe hierarchy
 280         - move common code to base class
 281         - make sure all record classes use the common record API
 282         - test
 283 Estimated time: 7 hours
 284
 285
 286
 287 C API wrapper
 288 -------------
 289 For those that write applications in C, a C API wrapper has been started
 290 in the cbarry.h header.  It has not yet been implemented, but should be
 291 straightforward.
 292
 293 Estimated tasks:
 294         - finish some API design work (head not fully complete)
 295         - implement all functions (about 50)
 296         - write test application, or test suite, for C API
 297 Estimated time: unknown
 298
 299
 300
 301 Python wrappers and example code
 302 --------------------------------
 303 For those that write applications in Python, a SWIG wrapper has been
 304 started by H Miz Jones.  This is partially functional, and involves
 305 working with the Barry API, and may introduce changes to it depending
 306 how hard it is to translate things to the Python world.
 307
 308 The SWIG wrapper scripts have not yet been publically released, but
 309 please contact me if you are interested.
 310
 311 Estimated tasks:
 312         - finish C++ / Python integration (possible template issues)
 313         - finish SWIG wrapper
 314 Estimated time: unknown
 315
 316
 317
 318 Misc Low Level Todo Items:
 319 --------------------------
 320 - test whether sorting of contact records is required before
 321         uploading data to the device... test whether it is ok
 322         to upload a GroupLink item in the middle of a contact
 323         upload, even before all the groups have been sent...
 324         if ok, remove the sorting code from Contact, Message, and
 325         Calendar classes
 326