[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: imap jobs page
From:       Till Adam <till () adam-lilienthal ! de>
Date:       2003-05-06 11:57:58
[Download RAW message or body]

On Monday 05 May 2003 17:50, Marc Mutz wrote:
> On Monday 05 May 2003 12:02, Till Adam wrote:
> > On Sunday 04 May 2003 19:45, Marc Mutz wrote:

[snip]

> > Also, I find the ability
> > to mix server side and client side filtering a very valid requirement
> > in a MUA. I don't see a technical reason to disallow it. What exactly
> > do you see as problematic with having new mail in several folders per
> > account?
> >
> :-( You should probably download the list archive :-)

I'll gladly do that. Are they available in mbox format, or can someone make me 
a tarball? The web interface is a little awkward.

> The problem here is that if two clients connect and each apply their
> filters and these filters are not in sync, then they can start playing
> ping-pong with mails (client A moves them to folder X, client B sees
> them as new there and moves them to folder Y where client A sees them
> as new and moves them back to folder X etc etc.)
>
> I know people here doubt the validity of this arguments, but if you go
> into companies, you will see exactly this setup. The BSI wanted the
> _same_ account to be usable from both Outlook and KMail (and mutt and
> Mozilla, btw) _interchangeably_, perhaps (I'm not sure) even
> concurrently. That are even two completely different clients (as
> opposed to KMail/Work and KMail/Home e.g.).
>
> Add confused users calling the help desk b/c when they use KMail, mail
> from foo@bar.com goes to folder X, while when they use BazMail, it pops
> up in folder Y, and you have a pretty good picture of the issue. :-)

Ok, I see the issue, but from my perspective, that means we have two 
conflicting interests, where I want to do Bad Thing 1 (filter server and 
client side) and $BigCompany wants to do Bad Thing 2 (have it work with 
several concurrent clients). Now, I don't think my requirement to be 
unreasonable  and they consider theirs to be valid as well, of course.

Let's assume we allow both. I can then happily do my bad thing and make myself
a policy whereby I prohibit myself from using more than one client at a time. 
I control the server, and I control the client, there is no problem. 
$BigCompany can make themselves a policy wherby they don't mix server side and 
client side filtering. They won't do that anyhow, it's a bad thing, afterall. 
They can happily use several clients concurrently, there is no problem.

Now, you cannot disallow $BigCompany's bad thing, how would you, after all, 
and why would you want to, but you seem to think that disallowing my bad thing 
is necessary.

The Right Thing (TM) imho would be to disallow what really causes problems, 
which is doing both at the same time. Since I can't think of a way to do that
in the MUA, I guess it can only be solved on a policy level.

> Please also note $sig.

Duely noted. ;)

> > > BTW: If the people working on IMAP (and thankfully we now have more
> > > than one of them) would first merge the dIMAP with online IMAP
> > > code, stuff will become a lot easier in the middle to long run for
> > > them.
> >
> > Ok. What excatly do you mean by "merge" ? Simply give up online imap
> > in favour of dIMAP? Share more code? Port online imap to maildir and
> > do a bit of caching when a message is donwloaded anyhow? Sorry if
> > this has been discussed before, but I don't have a clear picture of
> > what you envision.
>
> Bo planned to make online vs. disconnected mode (and anything in
> between, like "d/l no attachments (greater than x kB)", "d/l only
> headers", "d/l nothing") a Strategy Pattern (see [GoF]) to a single
> IMAP account class. I was thinking about moving the disconnected/cached
> logic to the IMAP slave (like for the http slave), but this has locking
> issues (which presumably can be solved by using maildir as the cache
> format, which doesn't require locking), so it was dismissed in
> Osnabrueck.
>
> I don't know what exactly Bo is up to and in which time frame, but I
> guess he's done more thinking about the issue than most of us (he
> implemented dIMAP in kroupware_branch).
>
> Here's what I think he wanted to do: From the user perspective (and the
> class structure), there is only one IMAP account type. Per-account and
> per-folder options define what is being cached and what isn't.

Ah, thanks a lot. That actually makes a great deal of sense. I think I will 
consider the imap stuff to be in bugfix only mode, for the time being, and not 
work on new features for it. I guess we need to agree on what steps are to be 
taken and who writes what code in what timeframe. Can we maybe arrange for
something like an "IMAP in KMail - The road to ElDorado" irc meeting sometime
in the not too distant future? Maybe the weekend May 23d to 25th? Are we all 
in the same timezone? Hell, if we are all in germany anyhow, we might as well 
meet in person somewhere. ;)

Till
_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail
[prev in list] [next in list] [prev in thread] [next in thread]