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.)

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.

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!")

So while it may seem frustrating, there are actual operational reasons for
certain conventions, and arbitrarily changing them will cause issues.

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.



-- 
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

Reply via email to