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.
9 <cdfrey@foursquare.net>
14 Porting opensync plugin to opensync 0.40
15 ----------------------------------------
16 There's two options to this item:
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
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
29 The proper way involves:
31 - switching from the vcard/vevent formats to the opensync XML
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
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.
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
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.
52 Estimated time: simple way: 10 hours if lucky
53 proper way: open ended
57 Reverse engineering java loader protocol
58 ----------------------------------------
59 This has not been done by any opensource Blackberry project out there,
60 to my knowledge, and would be most useful to Blackberry application
63 If you are a Blackberry app developer, this may interest you.
65 Estimated time: open ended
69 Adding GPRS / CDMA modem support
70 --------------------------------
71 Barry has had plans to include modem support for a few months now, but
72 it has not yet percolated to the surface.
74 The primary source for modem protocol specifics is the XmBlackBerry
75 project (http://sourceforge.net/projects/XmBlackBerry). Barry's
76 goal is to create a standalone pppob utility that can be configured
77 with pppd similarly to pppoe.
79 The tricky part of modem support is that it requires threading support,
80 especially if you intend to use the database at the same time.
81 This leads to some architectural challenges that need to be dealt with:
83 As Barry is not a single application, how do you access the
84 database while pppob is using the modem?
86 There are two viable ways of dealing with this. One involves placing
87 a (hopefully thin) driver in the kernel, and the other involves using
88 a daemon and RPC calls.
90 My preference is to implement this using RPC calls if needed, and hammer
91 out all the implementation details in user space. Once they are well
92 understood, a smaller kernel driver hook may be more easily written
93 that supports routing messages according to socket or application
94 needs. For example, one application may register an interest in
95 database messages, another in javaloader messages, and another in the
96 multiple modem socket messages.
98 There is currently a development branch in CVS that intends to support
99 optional threading support in the Barry library, so that at least
100 it should be possible to use both the database and the modem in the
103 Estimated tasks (assuming threading support is finished):
104 - copy protocol specifics from XmBlackBerry
105 - add Serial class for controller interface
106 - write and test pppob
107 - write pppob manpage
108 Estimated time: 8 hours
112 Finish the threaded architecture changes in CVS branch
113 ------------------------------------------------------
114 For the reasons outlined above, for modem support, this CVS branch
115 needs to be finished. For more information, contact the mailing list.
118 - write SocketRouting code
119 - refactor the controller class into RAII behaving
120 mode classes, such as Desktop, Serial, and
121 Javaloader, that operate on top of Controller
122 - testing threaded and non-threaded behaviour
123 - testing performance impact
124 Estimated time: 20 hours
128 Add bluetooth serial support
129 ----------------------------
130 It is reported that it is possible to access the database through
131 Bluetooth using the older Blackberry serial protocol. XmBlackBerry
132 has support for this and may be used as a reference.
134 The goal here would be to hide the bluetooth access behind the
135 same Barry library API, so that syncing with the opensync plugin
136 would be seamless whether plugged in via USB or Bluetooth.
139 - research and design serial protocol stack to reuse as much
140 library code as possible
141 Estimated time: unknown
145 Write simple GUI for streamlining sync setup and action
146 -------------------------------------------------------
147 Syncing setup and operation is currently a tedious, complicated task.
148 A GUI that performed all the detailed setup and configuration work,
149 for a Blackberry-specific sync, using opensync libraries and plugins
150 for Evolution, Sunbird, etc, would be very helpful.
152 This would be much easier for an experienced GUI programmer, but there is
153 a learning curve for the opensync API.
156 - document the settings required for Blackberry, and
157 all intended plugins required
158 - write application that:
159 - does the opensync configuration through the opensync
161 - scans the USB bus for available Blackberry devices using
163 - lives in the system tray watching for Blackberry devices
164 - if aiming for super ease of use, script a source build of
165 all needed opensync components and install in private
166 area to avoid conflict with system
167 Estimated time: unknown
168 Note: Depending how fast HAL, OpenSync, and Conduit are implemented,
169 this may never be needed... but if it existed today, there's a
170 lot of users who would be very happy...
174 Document the USB protocol
175 -------------------------
176 Currently the only english documentation for the Blackberry protocol
177 is the webpage by the Cassis project (found at
178 http://off.net/cassis/protocol-description.html).
180 The USB protocol is not nearly so well documented. The best documentation
181 available can be found in the Barry header files: protocol.h and
184 Translating the code into documentation (into a wiki, that will hopefully
185 soon be available) is a great way to get involved in the project and
186 learn a lot about the Blackberry from a low level.
188 Unfortunately, Jedi mind tricks don't often work when trying to convince
189 people to write documentation for me... :-)
192 - write, write, write
193 Estimated time: 40 hours (documentation expands to fill available time...)
199 Code can always be improved. There are two big ways to help:
201 - write an application using the Barry library
202 - improve the Barry library itself and send patches
204 By writing an application, you can provide crucial feedback on the ease
205 of use of the Barry API. I'm very eager for such feedback.
207 Secondly, there is currently a lot of code ducplication in the record
208 classes, and a careful refactoring is required. I would be open to a class
209 hierarchy, with possibly private or protected inheritance. My primary
210 concern is object safety when using the record classes as objects in
211 STL containers, with a secondary concern to make it easier to
212 abstractly work with a record. This implies a careful mix of
213 virtual functions and a generic record base class. Patches in this
214 area will be thoughtfully considered.
216 Estimated tasks (refactoring):
217 - design safe hierarchy
218 - move common code to base class
219 - make sure all record classes use the common record API
221 Estimated time: 7 hours
227 For those that write applications in C, a C API wrapper has been started
228 in the cbarry.h header. It has not yet been implemented, but should be
232 - finish some API design work (head not fully complete)
233 - implement all functions (about 50)
234 - write test application, or test suite, for C API
235 Estimated time: unknown
239 Python wrappers and example code
240 --------------------------------
241 For those that write applications in Python, a SWIG wrapper has been
242 started by H Miz Jones. This is partially functional, and involves
243 working with the Barry API, and may introduce changes to it depending
244 how hard it is to translate things to the Python world.
246 The SWIG wrapper scripts have not yet been publically released, but
247 please contact me if you are interested.
250 - finish C++ / Python integration (possible template issues)
251 - finish SWIG wrapper
252 Estimated time: unknown
256 Command line backup and restore
257 -------------------------------
258 The only command line backup currently available is the one in btool,
259 using the -f and -s switches. This does not backup exact data from
260 the device, but parses it, stores it in the Boost serialization format,
261 and then reverses the process for restore. This is a great test
262 for the Barry library, but not so great for backup, since not all
263 databases can be parsed.
265 There is already an exact backup and restore interface with the GUI, but
266 there is a lot of useful functionality trapped in a layer of GUI
267 that could be just as useful from the command line. Tasks such as a nightly
268 cron backup of any Blackberry devices attached to the system would be more
269 easily done via command line.
271 You could add command line arguments to the barrybackup program to skip
272 the GUI (tricky and possibly error prone), or you could pull the backup
273 functionality into a standalone command line utility (more work, but smarter
274 in the long run). This is mostly a code refactoring job, consisting of
275 all working code that's already there, and I know there are people
276 who would thank you. :-)
279 - split out tar and backup functionality code into shared library
280 - write and test command line tool
281 Estimated time: 6 hours
285 Misc Low Level Todo Items:
286 --------------------------
287 - test whether sorting of contact records is required before
288 uploading data to the device... test whether it is ok
289 to upload a GroupLink item in the middle of a contact
290 upload, even before all the groups have been sent...
291 if ok, remove the sorting code from Contact, Message, and