Project Speed

Last modified by mscott on February 06, 2000
link to current todo list

Introduction

Dave Hyatt recently suffered a bout of true inspiration and came up with a way to make a skinnable outliner widget that only knows "how to paint" and not reflow. This outliner widget behaves much like the 4.x outliner widget. A client implements a view that is bound to the outliner widget. The widget then asks the view for information like the row properties for the current rows it is currently painting. We believe that performance on the same order of magnitude as 4.x can be achieved using this outliner widget in mailnews for the following areas: In addition we would be making a substantial reduction in the amount of memory consumed by mailnews because loading a folder will no longer involve building a content model for all the messages in the data source.

Of course there's a cost to contrast all these gains. Using this new outliner widget would requiire us to completely re-write the mailnews front end. We would no longer be using RDF as the view for data in the thread pane. We would no longer be using the tree widet for the thread pane either. This document is intended to summarize the work we would need to do to convert mailnews to use this outliner widget. Hopefully by writing it, we'll also be able to figure out any XP Toolkit dependencies we would need in addition to just the outliner widget.

The Outliner Widget

A consumer of the outliner widget implements nsIOutlinerView which contains methods like get selection, get row properties, get cell properties, is container, is open etc. So it is the responsibility of the view to manage selection, and to provide properties and values for row and cell values in the outliner. The view talks to the outliner via nsIOutlinerBoxObject which allows the view to invalidate rows and cells or append rows. So the view actually tells the outliner when to invalidate rows or regions. It also fills in the information for each row the outliner is currently displaying.

Over time, we'll try to include or point to some example code showing you how to write a view for an outliner.

Outliner Views for MailNews

The following section attempts to list and describe the changes we need to make to the mailnews front end in order to use an outliner in the thread pane. For now, let's focuse on the thread pane and leave the folder data source alone. Time permitting we will attempt to conver the folder pane to use an outliner widget as well.

The first thing we need to do is to rebuild a view layer for mailnews. Currently RDF acts as our view and this is going to go away. Where is our view level going to live? One could easily implement nsIOutlinerView on each mailnews folder class. Methods like getRow properties would be easy to write when you can talk directly to a DBFolder. However, then the view and the model are the same and you can't really have multiple view of a folder. So clearly that isn't desireable. In 4.x, we had MSG_ViewIndices which you could use to map between a particular view and the actual entries in the data base. Operations like sorting and such were performed on the view indices. Let's assume we bring over something similar to the view indices. Some mailnews view issues

David Bienvenu added the following very helpful description of 4.x:

In 4.x a view contained three separate parallel arrays: the msg key array, the flags array (single byte), and the level array (which indicated the level of nesting). Each array was kept in order with the view. The view object listened to the DB that it was a view of, and when db notifications were received, updated the view appropriately, which in turn would notify the front end (in this case, the outliner). Since we're still sending notifications from the DB in 6.0, this should be easy enough to do.

There were separate view classes, however, for threaded views, and the threads with new view. The view is the class that builds up the content, so it makes sense for the different views to be different classes. The hierarchy was msgdbvw (which handled flat views), thrdbvw for threaded view, and thrnewvw for threads with new.

Many things in the MailFE will have to be re-written to work using the outliner widget. The following sub sections include descriptions of some of these including what we'll need to do in the new world.

Command Handling

We'll need to implement new command handling that won't rely on RDF. Something similar to 4.x where we intepret the command and the selection and perform the operation. This includes things like deleting, etc. I'm assuming there will be some xp toolkit dependencies here

Drag and Drop

We'll need drag and drop support in the outliner widget. Another xp toolkit dependency. Dave said pinkerton might be willing to help us out here. We'll need to invesigate this further.

Sorting

We will no longer be going through the rdf xul sort service to perform sorting. We'll need to do it on our own. This should improve performance for sorting as well! We need to make sure to watch out for any I18N issues RDF may have been taking care for us already when we do this.Where does the sorting code live? I'm assuming we'll always just be sorting a view.

Search

Currently the search front end leverages the fact that we use RDF. i.e. it is built out of a data source as well. In addition the search results pane is just a thread pane instance so it will need to use the outliner widget as well. This could be a lot of work. Gayatri is already working on new search features built out of the current search FE. If we obsolete this we need to get her involved in the loop early on.

Implementing Threads

We will have to revist how we implemented message threads in the thread pane. We'll also need some XP-toolkit help to implement the abiliity to show a "connected-ness" between messages in the same thread. In 4.x, this meant those little dotted lines that went from the parent message to the next message in the thread, to the next message, etc. We'll need a way to describe this with the outliner.

Context Menu

We'll need to revisit how we build the context menu for the thread pane. Is there a toolkit dependency here or is this something we implement on our own?

View Navigation

Putterman reminded me that we'll need to rewrite our view navigation code as this code currently uses RDF and the DOM. By doing it ourselves we'll be able to make things like show previous work again which we couldn't do through RDF.

Batching APIs for our Store

Now that we have total control over the view we want to batch updates and changes in the selection for the outliner widget. For instance, making sure we properly batch deletes when it comes to removing the selected items from the view. We may not have to do much here as I think our folder notifications for operations like delete are already batched.

Open Issues / Where to go?