[Evolution] VFolders vs Folders

[Ryan Heise <ryan whitewolf com au>]

I have read through all of the comments in reply to my email on virtual
folders. I am pleased to see that there were no objections to the
concept, only to implementation.

Conceptually, the folder attempts to serve the same function as an
attribute. When you create a folder called "evolution" and put 10 emails
into that folder, you are saying that all of these emails are related to
"evolution". You are saying that "evolution" is something that all of
these emails have in common. "evolution" is an attribute of all of those
emails. Now, suppose you cross-post an email to the evolution mailing
list and the bonobo mailing list (if it exists). Those emails will be
related to both "evolution" and "bonobo". "evolution" and "bonobo" are
both attributes of those emails. And, you would want them to appear in
both the evolution and bonobo folders.

Attributes and folders are two ways of looking at the "same thing" (*).
The user does not need to understand two types of folders because one is
just an extension of the other. Therefore, unified folders can be used
in a limited way like normal folders, or these same folders can be used
like VFolders if the user wants to take advantage of overlapping views.

(*) Actually, a (unified) folder /can/ map to one attribute, but it can
also map to an expression of attributes.


It is possible to design a user interface with one type of folder that
can be used just like normal folders if that's all they are familiar
with. And for that same type of folder to be used by advanced users who
wish to have the folder contents overlap with other folders. I believe
that if this user interface is designed right, it will be easier for
users to understand than having to learn two conflicting concepts. They
conflict in that often users may not know whether to create a folder of
a vfolder, and if we had just unified folders they would not need to
decide.

In the rest of this email, I will respond to the emails people made
about implementation issues:

Michael Poole wrote:

> Those two operations (adding an in-line attribute and filing into a
> separate storage) are equivalent, although as you point out if you can
> set multiple flags or attributes it becomes more flexible.  The
> difference between filtering and vfoldering is (in my mind) one-time
> processing -- usually on receipt or retrieval -- and retrieval based
> on certain criteria.  If those criteria are expensive to compute, then
> it's more efficient to use a static assignment.

Creating an index of emails with custom attribute "evolution" should be
roughly the same as creating a physical folder called "evolution", in
terms of viewing performance.

> you still have a potentially
> large decision graph (not quite a tree, because several rules in a
> sieve script can send mail to the same target, but it's close) for
> each folder.  In the general case, it will be costly to perform that
> search in real time.

If an index is roughly the same speed as a physical folder, then the
decision tree should take rougly the same time to calculate.

Adam Sleight wrote:

> 100 or 200MB+ IMAP mbox folders make take a few seconds when
> manipulating them (not good).  Having the ability to have many folders
> reduces that time since it doesn't have to parse through a single 200MB
> mbox file.

Sure. I am supportive of using different physical layouts for
efficiency. However, I feel that the functionality is too tied to (and
limited by) the physical representation. VFolders are powerful because
they don't map to any physical representation. An email can't be in two
places on disk, but it can be in two views at the user interface level.

You can solve the storage efficiency problem without forcing the user
interface to be based around the physical layout. With the mbox format,
users might set up several mboxes for efficiency. With Maildir, each
mail is in a separate file and this solves the problem by itself. But
this is all at the physical level, and different physical layouts should
not impact on how the user is able to view emails. However emails are
split up on disk, I would still like to be able to have cross-posted
emails (eg. bonobo+evolution) "appear" in two folders, etc.

Giao Nguyen wrote:

> I think people will use what feels best to them. Personally the extra few
> seconds is worth it but mileage may vary. "Real" folders and stores are
> synonmous. "Real" folders are just physically mapped and any physicallly
> mapped entity can become a storage facility. So you can't get rid of real
> folders at all because to have a vfolder you have to have a "real" folder
> to back it all up. It's a nice try though but I just don't see it happening
> regardless of permance issues.

Yes, physical folders or "partitions" will exist at the physical layer.
I am proposing that user interface folders not be the same as physical
partitions. The physical layer sort of has the same limitations that the
real world does. Real world folders and documents are physical. You can
only put a document in one folder or another. You cannot put a document
that is related to both in both folders because that is "physically"
impossible. But while the physical world has these limitations, the
"virtual" world doesn't.

Just as a final comment, my goal here is to justify this as a workable
alternative to having two different types of folders. By making the case
for unified folders, it makes it easier to compare the two ideas. The
idea may never be implemented, but hopefully it can be considered for
all its worth.

-- 
Ryan Heise

http://www.progsoc.uts.edu.au/~rheise/