On Jan 26, 2010, at 12:16 PM, John C. Welch wrote:
> 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.
No, but you can take it's oddities into account when designing a universal
solution.
The goal is obviously an IMAP client to works and behaves correctly, but I
think you could design a system the allows for more creative uses of the
protocol.
> How do you use other clients against the server when you're ignoring it?
I'm not advocating ignoring the server, only that we allow the user to define
how he chooses to interact with the server.
Again, the default is to the be right, with an allowance to be wrong if the
user so chooses.
>> 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.
The storage of the files isn't what I mean why I say "represent". What I mean
is that the local storage may or may not reflect what is stored on the server.
For instance, on the server, I may have a folder called "Sent", while locally I
have folders called "Sent to Mark", "Sent to John", etc.
Processing rules would allow me to tell Letters to move items in "Sent" to
local folders – just as you can do with rules in email clients – to other
folders. However, on synchronization, a processing rule could also merge those
folders back into the "Sent" folder on the server.
The first part is currently possible using rules in most email applications.
The second part isn't possible without mirroring and duplicating messages.
> 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?
I imagine Server interaction problems will be handled through whatever
mechanism is designed to handle errors.
As for the server administrator, I'd need a specific case to answer. "What
would I tell the server administrator" would vary based on the configuration,
problem, etc.
> 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.
Exactly. Rules are already a well-worn idea.
I'm just recommending extending Rules beyond just post-processing a message
after the client has already applied it's internal logic.
Essentially exposing all logic involved in the download and cache of messages
to the local store, to be modifiable and extendable for the user.
> Until you're having a problem accessing a server folder, and you're talking
> to support. Then everyone speaking the same language is important.
I don't mean to dismiss support issues, but if we're assuming we're aiming at
power-users, if the application veers off some well-defined thread, and talking
to support becomes slightly difficult in certain scenarios where a user has
done things in some truly weird way, that would be an issue for the user.
In general, I'm not considering the server administrator in any of my thoughts.
The user is what matters first.
> 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.
Maybe it's confusing because there are "rules", as in "rules the application
follows" and "Rules" as in "Rules the user sets up".
Whether exposed or not, every email client has a set of rules it follows when
synchronizing between the server and the local cache. The the rules are
generally very simple ("mirror this") doesn't mean the rule isn't there.
Exposing that chain to the user, and allowing him to modify it, doesn't
magically "not work".
_______________________________________________
[email protected] mailing list
List help: http://lists.ranchero.com/listinfo.cgi/email-init-ranchero.com
