WeSay Development Progress

Thanks to Cathy, we now have a revamped skin on our wiki. We also have acquired wesay.org so update your bookmarks.

I have been working on two areas of WeSay. The first is our data access layer. Db4o provides a read only IList when queried. In the prototype, I had wrapped that result and provided our own read-write IList that automatically kept the database up to date. With John’s databinding work, we decided to provide a IBindingList interface over db4o. I spent quite a bit of work creating tests for the various interfaces: IBindingList tests, IList tests, ICollection tests, IEnumerable tests. I had an implementation working with tests when we hit performance issues with filters and John found Marek Istvanek’s work on providing a binding list over db4o. I chose to only use his db4oList class and implemented my own Db4oBindingList since we won’t be needing the paging and didn’t want to take on the associated risk. I had to modify the Db4oList class so that it would pass my previous tests.

Another big change to the Db4oList class had to do with unregistering the PropertyChanged event on classes which implement INotifyPropertyChanged. A number of people have blogged about the “lapsed listener” problem which causes objects to remain in memory due to the event source retaining a reference to the listener after the listeners go out of scope.

The solution to this tricky issue is to either use weak delegates or require a call to dispose before the listener goes out of scope. Wesner Moise claims that implementing weak delegates is a difficult proposition with a number of casualties (Joe Duffy and Ian Griffiths) to date. I found three implementations that still purport to be correct: Greg Schechter (he also provides the best overview of the problem space), Xavier Musy, and John Stewien. We finally decided the best way to handle this was to remove the listener from the event source when dispose is called.

The other area is in moving our proof of concept lazy GTK nodestore to production standards. In the process I came across this blog entitled DataBinding an IList as DataSource for the Gtk.TreeView. This obviously peeked my interest. At first, I adapted his code to use an IList but when I tried to load the assembly, I discovered that templated classes cannot contain references to external methods, which makes sense so I’m back to using an IList. This is still a work in progress for me too, but you can check out what I’ve done in our subversion repository.

These have been an exciting last few days, as our prototype has got to the place where we can start getting some questions answered. Happily, our quick tests (just looking at the Windows Task Manager), show that we can load the prototype with a 32k-word Thai glossary in just a couple seconds on my laptop, using only 22 Megs of RAM. A test with only 5k words took just a meg or so less. So we effectively don’t have to care how big the user’s dictionary gets. Even scrolling through the list (which is very fast), the RAM usage doesn’t grow more than one meg, and then it drops back. Score one for db4o & Eric’s lazy TreeView. This doesn’t count the RAM used by the .net framework itself, though. On a mono install, we’ll have some overhead that we haven’t measured yet.