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 Frey
   9
  10
  11 Next Release Checklist (- todo, + done, x skipped)
  12 ==============================================================================
  13 Target: the 0.18.x series
  14         - continue adding better support for French and Spanish translations,
  15                 especially to the Desktop GUI
  16         - desktop: add java management GUI
  17         - website documentation:
  18                 - www documentation / howto for bjdwp and friends
  19                 - add docs for using libmtp with the Storm to access media
  20         - polish up bfuse, and add feature to split out fields
  21
  22 Target: release version 0.19
  23         - add record classes for Content Store based on
  24                 Martin Owens' doc/barry-research.ods
  25         - look at incorporating contrib/ into main tree, or at least
  26                 into binary packages and tests
  27         - support BlackBerry Z10?
  28
  29
  30
  31
  32 General Features
  33 ==============================================================================
  34
  35 Add firmware upgrade support via USB
  36 ------------------------------------
  37 Duplicate the firmware upgrade functionality of the RIM Windows
  38 software.  There are USB captures of this in the USB Capture Log
  39 archive at http://www.netdirect.ca/software/packages/barry/logs.php
  40
  41
  42 Add media management via USB
  43 ----------------------------
  44 The Windows version of desktop software has the ability to manage
  45 photos on the Blackberry that are not stored on a flash card, but
  46 are instead stored in the Blackberry's internal memory.
  47
  48 It is challenging, on some devices, to even copy such photos and
  49 media to the flash card.
  50
  51 Capture the USB traffic for this media management, and add support
  52 to Barry.
  53
  54
  55 Add HAL/dbus support to BarryBackup
  56 -----------------------------------
  57 The latest version of the backup program lists devices in a combo box,
  58 with a Reload button to handle new devices being plugged in.
  59
  60 Add an optional feature to listen to HAL/dbus for device addition and
  61 removal and update the list automatically.  Note that this must be
  62 optional, since some systems may not have HAL available at compile time
  63 (such as FreeBSD) or perhaps at runtime (HAL may not be running),
  64 and so the Reload button must be available.
  65
  66 Leave the Reload button even if HAL support is present, since the user
  67 may wish to control the list manually, or force a reload.
  68
  69
  70 Reverse engineer date/time functions
  71 ------------------------------------
  72 The date/time calculations in src/time.cc:Message2Time() are still not
  73 completely understood.  There is an explanation of sorts in an email
  74 from Brian Edginton on the mailing list, but there are odd constants, etc.
  75 Need to understand it fully and document it.
  76
  77 Mail from Brian Edginton on the topic:
  78 http://sourceforge.net/mailarchive/message.php?msg_id=200706291619.05854.edge%40edginton.net
  79
  80
  81 An automated test suite
  82 -----------------------
  83 Testing Barry will be a challenge, since an actual device is required
  84 for a large bulk of tests.  Ideally, it should be easy for someone to
  85 make a full backup of their device, donate it to science, and then
  86 restore their settings and data, since not everyone has a pure device
  87 for testing.
  88
  89 Things that need automated testing:
  90
  91         - test all possible compile options (finished, see test/)
  92         - test parsing of all supported records
  93         - test building of all supported records
  94         - test backup and restore, of random sets of databases, as well
  95                 as the "all databases" set
  96         - test LDAP / LDIF conversions
  97         - test test Boost serialization backups and restore
  98         - make sure it is possible to create records with the same
  99                 SHA1 sums, purely programmatically
 100         - test syncing of all fields, including international data / charsets
 101         - test password support, and password safety catch (bad passwd X times)
 102         - test modem functionality
 103
 104 Estimated time: open ended
 105
 106
 107
 108 Flesh out the Troubleshooting web doc
 109 -------------------------------------
 110 Every stumbling block that users run into should either be fixed
 111 in the code or binary package, or documented in a Troubleshooting
 112 document.  This troubleshooting document is already started, but
 113 contributions are welcome from all users!
 114
 115
 116
 117 Timezone support to opensync plugins
 118 ------------------------------------
 119 Support for timezones will likely stress the opensync API as well as
 120 the Barry API, but definitely needs to be done for completeness on both
 121 sides of the equation.
 122
 123 This may involve switching from the text based vcard formats to
 124 the opensync XML formats.
 125
 126 Estimated time:   open ended
 127
 128
 129
 130 Multi-program Database and Modem Access
 131 ---------------------------------------
 132 The architectural challenge:
 133
 134         As Barry is not a single application, how do you access the
 135         database while pppob is using the modem?
 136
 137 There are two viable ways of dealing with this.  One involves placing
 138 a (hopefully thin) driver in the kernel, and the other involves using
 139 a daemon and RPC calls.
 140
 141 My preference is to implement this using RPC calls if needed, and hammer
 142 out all the implementation details in user space.  Once they are well
 143 understood, a smaller kernel driver hook may be more easily written
 144 that supports routing messages according to socket or application
 145 needs.  For example, one application may register an interest in
 146 database messages, another in javaloader messages, and another in the
 147 multiple modem socket messages.
 148
 149 There is currently no support for this RPC daemon, but threading
 150 support already exists.
 151
 152 Estimated tasks:
 153         - design suitable RPC system
 154         - implement support in the Barry library so it works
 155                 with and without a daemon, using the same API
 156 Estimated time: open ended
 157
 158
 159
 160 Add bluetooth serial support
 161 ----------------------------
 162 It is reported that it is possible to access the database through
 163 Bluetooth using the older Blackberry serial protocol.  XmBlackBerry
 164 has support for this and may be used as a reference.
 165
 166 The goal here would be to hide the bluetooth access behind the
 167 same Barry library API, so that syncing with the opensync plugin
 168 would be seamless whether plugged in via USB or Bluetooth.
 169
 170 Estimated tasks:
 171         - research and design serial protocol stack to reuse as much
 172                 library code as possible
 173 Estimated time: unknown
 174
 175
 176
 177 Document the USB protocol
 178 -------------------------
 179 Currently the only english documentation for the Blackberry protocol
 180 is the webpage by the Cassis project (found at
 181 http://off.net/cassis/protocol-description.html).
 182
 183 The USB protocol is not nearly so well documented.  The best documentation
 184 available can be found in the Barry header files: protocol.h and
 185 protostructs.h.
 186
 187 Translating the code into documentation (into a wiki, that will hopefully
 188 soon be available) is a great way to get involved in the project and
 189 learn a lot about the Blackberry from a low level.
 190
 191 Unfortunately, Jedi mind tricks don't often work when trying to convince
 192 people to write documentation for me... :-)
 193
 194 Estimated tasks:
 195         - write, write, write
 196 Estimated time: 40 hours (documentation expands to fill available time...)
 197
 198
 199
 200 Code cleanup
 201 ------------
 202 Code can always be improved.  There are two big ways to help:
 203
 204         - write an application using the Barry library
 205         - improve the Barry library itself and send patches
 206
 207 By writing an application, you can provide crucial feedback on the ease
 208 of use of the Barry API.  I'm very eager for such feedback.
 209
 210 Secondly, there is currently a lot of code ducplication in the record
 211 classes, and a careful refactoring is required.  I would be open to a class
 212 hierarchy, with possibly private or protected inheritance.  My primary
 213 concern is object safety when using the record classes as objects in
 214 STL containers, with a secondary concern to make it easier to
 215 abstractly work with a record.  This implies a careful mix of
 216 virtual functions and a generic record base class.  Patches in this
 217 area will be thoughtfully considered.
 218
 219 Estimated tasks (refactoring):
 220         - design safe hierarchy
 221         - move common code to base class
 222         - make sure all record classes use the common record API
 223         - test
 224 Estimated time: 7 hours
 225
 226
 227
 228 C API wrapper
 229 -------------
 230 For those that write applications in C, a C API wrapper has been started
 231 in the cbarry.h header.  It has not yet been implemented, but should be
 232 straightforward.
 233
 234 Estimated tasks:
 235         - finish some API design work (head not fully complete)
 236         - implement all functions (about 50)
 237         - write test application, or test suite, for C API
 238 Estimated time: unknown
 239
 240
 241
 242 Python wrappers and example code
 243 --------------------------------
 244 For those that write applications in Python, a SWIG wrapper has been
 245 started by H Miz Jones.  This is partially functional, and involves
 246 working with the Barry API, and may introduce changes to it depending
 247 how hard it is to translate things to the Python world.
 248
 249 The SWIG wrapper scripts have not yet been publically released, but
 250 please contact me if you are interested.
 251
 252 Estimated tasks:
 253         - finish C++ / Python integration (possible template issues)
 254         - finish SWIG wrapper
 255 Estimated time: unknown
 256
 257
 258
 259 Other ways to help:
 260 ==============================================================================
 261
 262 Devel Distro Tester
 263 -------------------
 264         Some distros release very early, and it is possible to follow
 265         along their development cycle.  These distros include Fedora,
 266         Ubuntu, and Debian.  There have already been some people reporting
 267         bugs on pre-release versions of distros, and that has been very
 268         helpful in ironing out kernel bugs, etc.
 269
 270         To help, build and test the latest stable and git Barry on
 271         whatever distros you have available, and report bugs to the
 272         mailing list.
 273
 274
 275 Compile Checker
 276 ---------------
 277         If you have access to cutting edge GCC versions, please submit any
 278         compiler issues you find to the mailing list.
 279
 280
 281 Documentation Pages
 282 -------------------
 283         You can help by periodically reviewing the web docs or
 284         man pages, and submit patches or correction notes to the mailing
 285         list.
 286
 287
 288 Downstream Monitor
 289 ------------------
 290         Ideally, downstream distro bugs are handled by the individual
 291         package maintainers, but any bugs that are too hard to solve at
 292         the distro level should be passed along upstream.  I follow the
 293         Debian package bugs, but other distros could use some help.
 294
 295         Also, for distro package maintainers, if you have a patch you
 296         apply regularly to Barry, and if it can be incorporated into
 297         upstream Barry, please send your patch to me via the mailing list.
 298         I'd like to keep Barry as up-to-date with such fixes as possible.
 299
 300
 301 Windows World Spy
 302 -----------------
 303         To help here, test every feature on new Blackberry models and
 304         official desktop software, and report what can be done with them
 305         that you can't do on the previous model.
 306
 307         There should be a document listing all these features so
 308         we know what to test against.  We can add these features to this
 309         TODO file, or start a new file under doc/ if you like.
 310
 311
 312 Tech Support Liaison
 313 --------------------
 314         There are many web support forums out there, where end users
 315         discuss software and techniques.  Unfortunately, I am unable to
 316         follow all these forums, looking for Barry and BlackBerry handheld
 317         related posts.  But if you are a member of such a forum, you can
 318         help Barry by responding to such topics, and if appropriate,
 319         forwarding a link to the mailing list, so bugs can be fixed.
 320
 321
 322 Purity Advisor
 323 --------------
 324         Upstream distros tend to change how they do things, or change their
 325         official policies from time to time.  If you are a distro user
 326         who keeps up to date with these changes, you can help by
 327         reporting if Barry's binary packaging or software is doing
 328         something that is out of date or deprecated.  Even better, please
 329         document how it should be done instead.
 330