| blob | 46051d9c7bf32b165f3896001ca24e8653846b18 |
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.
5 If you would like help or more information on any of these items,
6 please ask on the mailing list as well.
8 - Chris
9 <cdfrey@foursquare.net>
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
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
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
54 General Features
55 ==============================================================================
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
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.
70 It is challenging, on some devices, to even copy such photos and
71 media to the flash card.
73 Capture the USB traffic for this media management, and add support
74 to Barry.
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.
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.
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.
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.
99 Mail from Brian Edginton on the topic:
100 http://sourceforge.net/mailarchive/message.php?msg_id=200706291619.05854.edge%40edginton.net
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.
111 Things that need automated testing:
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
126 Estimated time: open ended
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!
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.
145 This may involve switching from the text based vcard formats to
146 the opensync XML formats.
148 Estimated time: open ended
152 Multi-program Database and Modem Access
153 ---------------------------------------
154 The architectural challenge:
156 As Barry is not a single application, how do you access the
157 database while pppob is using the modem?
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.
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.
171 There is currently no support for this RPC daemon, but threading
172 support already exists.
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
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.
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.
192 Estimated tasks:
193 - research and design serial protocol stack to reuse as much
194 library code as possible
195 Estimated time: unknown
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.
206 This would be much easier for an experienced GUI programmer, but there is
207 a learning curve for the opensync API.
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...
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).
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.
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.
242 Unfortunately, Jedi mind tricks don't often work when trying to convince
243 people to write documentation for me... :-)
245 Estimated tasks:
246 - write, write, write
247 Estimated time: 40 hours (documentation expands to fill available time...)
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.
259 Code cleanup
260 ------------
261 Code can always be improved. There are two big ways to help:
263 - write an application using the Barry library
264 - improve the Barry library itself and send patches
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.
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.
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
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.
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
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.
308 The SWIG wrapper scripts have not yet been publically released, but
309 please contact me if you are interested.
311 Estimated tasks:
312 - finish C++ / Python integration (possible template issues)
313 - finish SWIG wrapper
314 Estimated time: unknown
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
330 Other ways to help:
331 ==============================================================================
333 Devel Distro Tester
334 -------------------
335 Some distros release very early, and it is possible to follow
336 along their development cycle. These distros include Fedora,
337 Ubuntu, and Debian. There have already been some people reporting
338 bugs on pre-release versions of distros, and that has been very
339 helpful in ironing out kernel bugs, etc.
341 To help, build and test the latest stable and git Barry on
342 whatever distros you have available, and report bugs to the
343 mailing list.
346 Compile Checker
347 ---------------
348 If you have access to cutting edge GCC versions, please submit any
349 compiler issues you find to the mailing list.
352 Documentation Pages
353 -------------------
354 You can help by periodically reviewing the web docs or
355 man pages, and submit patches or correction notes to the mailing
356 list.
359 Downstream Monitor
360 ------------------
361 Ideally, downstream distro bugs are handled by the individual
362 package maintainers, but any bugs that are too hard to solve at
363 the distro level should be passed along upstream. I follow the
364 Debian package bugs, but other distros could use some help.
366 Also, for distro package maintainers, if you have a patch you
367 apply regularly to Barry, and if it can be incorporated into
368 upstream Barry, please send your patch to me via the mailing list.
369 I'd like to keep Barry as up-to-date with such fixes as possible.
372 Windows World Spy
373 -----------------
374 To help here, test every feature on new Blackberry models and
375 official desktop software, and report what can be done with them
376 that you can't do on the previous model.
378 There should be a document listing all these features so
379 we know what to test against. We can add these features to this
380 TODO file, or start a new file under doc/ if you like.
383 Tech Support Liaison
384 --------------------
385 There are many web support forums out there, where end users
386 discuss software and techniques. Unfortunately, I am unable to
387 follow all these forums, looking for Barry and BlackBerry handheld
388 related posts. But if you are a member of such a forum, you can
389 help Barry by responding to such topics, and if appropriate,
390 forwarding a link to the mailing list, so bugs can be fixed.
393 Purity Advisor
394 --------------
395 Upstream distros tend to change how they do things, or change their
396 official policies from time to time. If you are a distro user
397 who keeps up to date with these changes, you can help by
398 reporting if Barry's binary packaging or software is doing
399 something that is out of date or deprecated. Even better, please
400 document how it should be done instead.