On Sat, 29 Jun 2002 11:03:44 +0200 (CEST) Thomas Finneid <[EMAIL PROTECTED]> wrote:
TF> Could you give some examples of the problems you face with searching ? The problem is not with the searching itself, but with the impossibility to do anything with the results: just try searching for something in a folder containing 1000 messages. Mahogany will gladly tell you that it has found (and selected in the list control) 8 matching messages -- and then let you to [try to!] find them among the 1000 ones. This is really as user unfriendly as it gets. TF> I have never used it because I have found that it doesn`t work very well. Hmm, I don't know of any bugs in searching per se, please let me know of any. TF> But, it would be good to have a proper search mechanism, I have sorely TF> missed it. The only (but very useful) expansion I have in mind is multi folder search. But this requires the change to the presentation of the search results to be done first. TF> By virtual folders, you mean a folder that shows selected content from TF> other, real, folders? or perhaps as Ujwal called it, "Views"? TF> Is there any thing more to virtual folders than this? There are 2 possibilities here and my question, in fact, was which one did we need: 1. a virtual folder contains a (static) list of pointers to the messages in the other folders -- this is well suited to the "search results" window and is easy to implement 2. a virtual folder is defined by a "filter" (!= existing M filters) which tells it to select all matching messages from some other folder(s): the problem here is that when the other folders are updated, this one should be updated as well which creates all kinds of new problems. TF> > 1. should we have one global "Search results" or several of them? TF> > TF> > -> probably several as otherwise you wouldn't be able to search TF> > for a few things in parallel TF> TF> By global search result, I presume you mean just one result window. Yes. TF> First of all, that depends on how well M can multitask, but also how well TF> the mail server can. No, there will be anyhow only one search operation going on at any moment (until M is multi threaded, but this is a different story alltogether). But with only one search results folder you wouldn't be able to search first in folder A and then in folder B -- the results of the second search would overwrite the results of the first one. TF> Virtual folders in itself sounds like a good idea, but there are some TF> consequences. If it is only used for search results, or rather collating TF> information without allowing the user to modify the collection, We could make them read only at first but allowing the user to modify the message flags and even delete them doesn't seem to be difficult to implement (deleting them will only delete the "alias", the message would still stay in the original folder). TF> then the issues aren�t too difficult. Maybe, but I still don't see which options should it use. Remember, options in M means a Profile object, i.e. a path in the config. What path should a virtual folder have if it doesn't appear in the folder tree? Or does it? TF> Another issue is if the user deletes a message in a virtual folder, TF> does that mean he also wants to delete the real message or just the TF> reference. The latter IMHO. But, again, I didn't mean to discuss it now but rather focus on the problem at hand. TF> A third issue is how do we handle virtual folders built on collated TF> information from other virtual folder, in arbitrary depths. Should this be TF> allowed? Yes. TF> and what happens if any of the intermediate virtual folders are TF> deleted? The same thing as with the normal folders -- the messages disappear from the virtual folder as well. Regards, VZ ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Mahogany-Developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mahogany-developers
