TODO

This file contains features that need work.  If you wish to tackle
any of them, please post a quick message to the mailing list of your
intentions, in order to avoid duplication of effort.

If you would like help or more information on any of these items,
please ask on the mailing list as well.

Chris Frey


Next Release Checklist (- todo, + done, x skipped)
==============================================================================
Target: the 0.18.x series
	- continue adding better support for French and Spanish translations,
		especially to the Desktop GUI
	- desktop: add java management GUI
	- website documentation:
		- www documentation / howto for bjdwp and friends
		- add docs for using libmtp with the Storm to access media
	- polish up bfuse, and add feature to split out fields

Target: release version 0.19
	- add record classes for Content Store based on
		Martin Owens' doc/barry-research.ods
	- look at incorporating contrib/ into main tree, or at least
		into binary packages and tests
	- support BlackBerry Z10?




General Features
==============================================================================

Add firmware upgrade support via USB
------------------------------------
Duplicate the firmware upgrade functionality of the RIM Windows
software.  There are USB captures of this in the USB Capture Log
archive at http://www.netdirect.ca/software/packages/barry/logs.php


Add media management via USB
----------------------------
The Windows version of desktop software has the ability to manage
photos on the Blackberry that are not stored on a flash card, but
are instead stored in the Blackberry's internal memory.

It is challenging, on some devices, to even copy such photos and
media to the flash card.

Capture the USB traffic for this media management, and add support
to Barry.


Add HAL/dbus support to BarryBackup
-----------------------------------
The latest version of the backup program lists devices in a combo box,
with a Reload button to handle new devices being plugged in.

Add an optional feature to listen to HAL/dbus for device addition and
removal and update the list automatically.  Note that this must be
optional, since some systems may not have HAL available at compile time
(such as FreeBSD) or perhaps at runtime (HAL may not be running),
and so the Reload button must be available.

Leave the Reload button even if HAL support is present, since the user
may wish to control the list manually, or force a reload.


Reverse engineer date/time functions
------------------------------------
The date/time calculations in src/time.cc:Message2Time() are still not
completely understood.  There is an explanation of sorts in an email
from Brian Edginton on the mailing list, but there are odd constants, etc.
Need to understand it fully and document it.

Mail from Brian Edginton on the topic:
http://sourceforge.net/mailarchive/message.php?msg_id=200706291619.05854.edge%40edginton.net


An automated test suite
-----------------------
Testing Barry will be a challenge, since an actual device is required
for a large bulk of tests.  Ideally, it should be easy for someone to
make a full backup of their device, donate it to science, and then
restore their settings and data, since not everyone has a pure device
for testing.

Things that need automated testing:

	- test all possible compile options (finished, see test/)
	- test parsing of all supported records
	- test building of all supported records
	- test backup and restore, of random sets of databases, as well
		as the "all databases" set
	- test LDAP / LDIF conversions
	- test test Boost serialization backups and restore
	- make sure it is possible to create records with the same
		SHA1 sums, purely programmatically
	- test syncing of all fields, including international data / charsets
	- test password support, and password safety catch (bad passwd X times)
	- test modem functionality

Estimated time: open ended



Flesh out the Troubleshooting web doc
-------------------------------------
Every stumbling block that users run into should either be fixed
in the code or binary package, or documented in a Troubleshooting
document.  This troubleshooting document is already started, but
contributions are welcome from all users!



Timezone support to opensync plugins
------------------------------------
Support for timezones will likely stress the opensync API as well as
the Barry API, but definitely needs to be done for completeness on both
sides of the equation.

This may involve switching from the text based vcard formats to
the opensync XML formats.

Estimated time:   open ended



Multi-program Database and Modem Access
---------------------------------------
The architectural challenge:

	As Barry is not a single application, how do you access the
	database while pppob is using the modem?

There are two viable ways of dealing with this.  One involves placing
a (hopefully thin) driver in the kernel, and the other involves using
a daemon and RPC calls.

My preference is to implement this using RPC calls if needed, and hammer
out all the implementation details in user space.  Once they are well
understood, a smaller kernel driver hook may be more easily written
that supports routing messages according to socket or application
needs.  For example, one application may register an interest in
database messages, another in javaloader messages, and another in the
multiple modem socket messages.

There is currently no support for this RPC daemon, but threading
support already exists.

Estimated tasks:
	- design suitable RPC system
	- implement support in the Barry library so it works
		with and without a daemon, using the same API
Estimated time: open ended



Add bluetooth serial support
----------------------------
It is reported that it is possible to access the database through
Bluetooth using the older Blackberry serial protocol.  XmBlackBerry
has support for this and may be used as a reference.

The goal here would be to hide the bluetooth access behind the
same Barry library API, so that syncing with the opensync plugin
would be seamless whether plugged in via USB or Bluetooth.

Estimated tasks:
	- research and design serial protocol stack to reuse as much
		library code as possible
Estimated time: unknown



Document the USB protocol
-------------------------
Currently the only english documentation for the Blackberry protocol
is the webpage by the Cassis project (found at
http://off.net/cassis/protocol-description.html).

The USB protocol is not nearly so well documented.  The best documentation
available can be found in the Barry header files: protocol.h and
protostructs.h.

Translating the code into documentation (into a wiki, that will hopefully
soon be available) is a great way to get involved in the project and
learn a lot about the Blackberry from a low level.

Unfortunately, Jedi mind tricks don't often work when trying to convince
people to write documentation for me... :-)

Estimated tasks:
	- write, write, write
Estimated time: 40 hours (documentation expands to fill available time...)



Code cleanup
------------
Code can always be improved.  There are two big ways to help:

	- write an application using the Barry library
	- improve the Barry library itself and send patches

By writing an application, you can provide crucial feedback on the ease
of use of the Barry API.  I'm very eager for such feedback.

Secondly, there is currently a lot of code ducplication in the record
classes, and a careful refactoring is required.  I would be open to a class
hierarchy, with possibly private or protected inheritance.  My primary
concern is object safety when using the record classes as objects in
STL containers, with a secondary concern to make it easier to
abstractly work with a record.  This implies a careful mix of
virtual functions and a generic record base class.  Patches in this
area will be thoughtfully considered.

Estimated tasks (refactoring):
	- design safe hierarchy
	- move common code to base class
	- make sure all record classes use the common record API
	- test
Estimated time: 7 hours



C API wrapper
-------------
For those that write applications in C, a C API wrapper has been started
in the cbarry.h header.  It has not yet been implemented, but should be
straightforward.

Estimated tasks:
	- finish some API design work (head not fully complete)
	- implement all functions (about 50)
	- write test application, or test suite, for C API
Estimated time: unknown



Python wrappers and example code
--------------------------------
For those that write applications in Python, a SWIG wrapper has been
started by H Miz Jones.  This is partially functional, and involves
working with the Barry API, and may introduce changes to it depending
how hard it is to translate things to the Python world.

The SWIG wrapper scripts have not yet been publically released, but
please contact me if you are interested.

Estimated tasks:
	- finish C++ / Python integration (possible template issues)
	- finish SWIG wrapper
Estimated time: unknown



Other ways to help:
==============================================================================

Devel Distro Tester
-------------------
	Some distros release very early, and it is possible to follow
	along their development cycle.  These distros include Fedora,
	Ubuntu, and Debian.  There have already been some people reporting
	bugs on pre-release versions of distros, and that has been very
	helpful in ironing out kernel bugs, etc.

	To help, build and test the latest stable and git Barry on
	whatever distros you have available, and report bugs to the
	mailing list.


Compile Checker
---------------
	If you have access to cutting edge GCC versions, please submit any
	compiler issues you find to the mailing list.


Documentation Pages
-------------------
	You can help by periodically reviewing the web docs or
	man pages, and submit patches or correction notes to the mailing
	list.


Downstream Monitor
------------------
	Ideally, downstream distro bugs are handled by the individual
	package maintainers, but any bugs that are too hard to solve at
	the distro level should be passed along upstream.  I follow the
	Debian package bugs, but other distros could use some help.

	Also, for distro package maintainers, if you have a patch you
	apply regularly to Barry, and if it can be incorporated into
	upstream Barry, please send your patch to me via the mailing list.
	I'd like to keep Barry as up-to-date with such fixes as possible.


Windows World Spy
-----------------
	To help here, test every feature on new Blackberry models and
	official desktop software, and report what can be done with them
	that you can't do on the previous model.

	There should be a document listing all these features so
	we know what to test against.  We can add these features to this
	TODO file, or start a new file under doc/ if you like.


Tech Support Liaison
--------------------
	There are many web support forums out there, where end users
	discuss software and techniques.  Unfortunately, I am unable to
	follow all these forums, looking for Barry and BlackBerry handheld
	related posts.  But if you are a member of such a forum, you can
	help Barry by responding to such topics, and if appropriate,
	forwarding a link to the mailing list, so bugs can be fixed.


Purity Advisor
--------------
	Upstream distros tend to change how they do things, or change their
	official policies from time to time.  If you are a distro user
	who keeps up to date with these changes, you can help by
	reporting if Barry's binary packaging or software is doing
	something that is out of date or deprecated.  Even better, please
	document how it should be done instead.