On Jan 26, 2010, at 8:29 AM, John C. Welch wrote: > On 1/26/10 9:13 AM, "Jack Shedd" <[email protected]> wrote: > >> >> Maybe this is way to far out there, and maybe it doesn't make any sense, but >> I'm interested to hear what other people think. > > It's an interesting idea, but the problem is the IMAP server. (not Gmail. > Let me be very clear, that if I say "IMAP" or "IMAP server" I'm never > talking about that mess.) > > IMAP servers tend to have folder structures. Right or wrong, that's how it > is. Some attempts have been made to do this differently, but the only one > that's 'succeeded' are things like Exchange and whatever Oracle's toy is, > and neither of those are really IMAP servers. (if you want a great example > of why no, plugins for core functionality can be a trap, Exchange and IMAP > would be a great example of how that can go wrong.)
"Tend to" doesn't mean always do, and while it might be easy to ignore Gmail, and the mess that is it's IMAP implementation, it IS one of the more popular IMAP servers out there. While it may not be "right" it does introduce the possibility of the folders concept not being absolute between implementations. That said, nothing in my idea precludes the use of folders. You could just as easily define a ruleset which handles everything by the book, mirroring the server folder structure to a local structure, setting all flags precisely the same, etc. However, it would allow for you NOT to do that, which I think could be incredibly powerful. > So for an IMAP client to accurately represent what's on the server, (a > non-optional function), it has to deal with folders. When a new message > comes into the server, barring Sieve or some such, it goes into the Inbox > folder. Your IMAP client the replicates this locally, as either a cached or > non-cached view of the server. Not necessarily. An IMAP client should accurately represent what's on the server – if that's what the user wants. But it could just as easily be something amazingly different. First, let's separate out two concerns. First, is that, when connecting to a server, I should, as a user, be able to view, in some way, the absolute structure of my account as the server advertises it. However, that I would want that exact structure on my local machine, or that that exact structure is how I will be interacting with that mail server, is something that, if we're targeting power-users at least, might be left up to the user. As an example, I have a few email accounts that have been setup with the express purpose of handling crash reports from our software. Now, in many cases, the bug has already been fixed in a local development copy, and I no longer need to review or care about these. I've setup server-side processing rules on Gmail to filter all of these out into separate server-side folders which delete on a 15-day rotation. Because I connect to my mail through an iPhone, and don't want the damn thing spending all day retrieving mail, but DO need it to fetch those reports which I haven't yet handled, I have it watching my inbox and ignoring every other server folder. But on my home machine, I may want to download those messages and do something else with them, i.e. I may want to have the incoming messages redirected to a another email account, or copied to one of employees, etc etc. If you take away the assumption that Letters will act as (essentially) a view into, and manipulator of, the IMAP, and consider instead that it merely understands and can act on mail from an IMAP server, a good deal of functionality and approach options open up. > As well, you have to have an 'account' object, because rules or not, there > are certain account-level settings you simply have to deal with. > Authentication, trash handling, et al that would be really annoying to deal > with in rules. So sanity pushes you to have an account object. The server > requires you to have folders. You can label them whatever you like, but > they're folders, otherwise you're going to have issues communicating with > the server. (getting too clever here makes communicating with the server > administrator hard. "Is it in your inbox?" "Oh my client calls it a > reception blob." "is it in there?" "No, new mail goes to the new mail blob" > "do you perchance have a mail client that was not programmed by the insane?" > "my hed is pasted on yay!") The "server" could do whatever it pleases with my mail. In my concept, I see that what happens on the server and what happens in my client can be two very different things, or the same thing, depending. > So while it may seem frustrating, there are actual operational reasons for > certain conventions, and arbitrarily changing them will cause issues. Perhaps I was unclear, Folders would not go away, or even change label. I'm only talking about the UI and process by which a user sets up their account, downloads messages and acts on them. > As well, those of us with extensive server and client rules kind of do that > now. For example in my case, to stay in the Inbox on the server, a message > has 'survived' a large gauntlet of rules on that server. Once I connect with > a client, I've an even longer set of 'normal' and mailing list rules that it > has to 'survive' to stay in the inbox. Right, most power users have an extensive collection of rules, I think. I'm advocating that you make "Rules" the defacto way by which the UI handles synchronization and actions. _______________________________________________ [email protected] mailing list List help: http://lists.ranchero.com/listinfo.cgi/email-init-ranchero.com
