2
edits
Changes
→More of a Server-client Approach to folders?: new section
May I finally add my screenshot visualizing ''some'' of your proposals already below? http://home.arcor.de/david-peters/TB.png
== More of a Server-client Approach to folders? ==
Noting the number of suggestions to do with importing/viewing/organizing messages in folders, might it be a good idea to take the client-server approach further to allow more flexibility and minimize disruption in the future as major changes may occur to implement changes that are seen as important now? You can either think of it as an evolution to an "IMAP-on-steroids", or as a major redesign so that TB is split into two parts - one that is a local server to look after all message filing and searching (that may use a database, may access an unmodified Outlook files, etc) and the other half does the display (and that could even be implemented simply as a web page in firefox).
The underlying mechanism for communication between the two halves would have to take into account all the changes suggested now, plus more. I imagine it would have a very fluid idea of what a "folder" is... messages could be in several folders (by date, sender, subject, keywords) and should allow for virtual folders (like the old VMS email system).
Another thing this may help with is situations that exists when some folders are shared, e.g. if several people may respond to a support (or sales, etc) email, depending on who is available first; messages could be handled by the server part in such a way as to allow automatic re-filing in different folders depending on the extent to which they are processed, including showing if someone else has 'checked out" the message to respond to it.
Advantages: users could choose a small/simple server or a complex one, irrespective of the front end (and so save RAM, or gain speed, or features). Developers could benefit from a pair of smaller projects, not having to worry about complications internal to the other section; and making the change could nudge certain long-standing problems to be thought out to make a neatly organized plan, even if the implementation of them in each end still needs work.
I think (maybe I'm wrong) that this is an easy transition plan for what amounts to significant re-thinks in message storage, and I think it isn't far from some things already in motion, but I don't think that direction is enough of a priority at the moment.
