On 1/26/10 9:50 AM, "Jack Shedd" <[email protected]> wrote:
>> 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. Design for Gmail and hope other IMAP servers don't vomit, or Design for IMAP and accept that Gmail will always be strange, and build in custom code to deal with that. That's really the only option. You can't pretend like Gmail is imap. > > 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. How do you use other clients against the server when you're ignoring it? > >> 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. How? You have files in directories. Or if you want to be Entourage, files in a database. > > 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. And how do you then deal with server interaction problems? What do you tell the server administrator, who needs to know what you're seeing? > > 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. I can think of a gob of current clients that will do that *now*. In fact, the one I'm using does that all the time. This is not new, nor particularly exciting. It's just what you get from a robust rules implementation. I think even mail can do it, but I hate Mail, so I'm not sure. > >> 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. Until you're having a problem accessing a server folder, and you're talking to support. Then everyone speaking the same language is important. This of course is never a problem with Gmail. Google has no support for Gmail, and all problems are your fault for not using the web client. I'm not sure that's a great model for Letters. > >> 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. On a very basic level, that is what happens. However, you have to decide what to do with no rules, and if you're saying "Without Rules, you have no functionality" then no, that's not going to work. -- John C. Welch Writer/Analyst Bynkii.com Mac and other opinions [email protected] _______________________________________________ [email protected] mailing list List help: http://lists.ranchero.com/listinfo.cgi/email-init-ranchero.com
