[Kde-pim] Moving Trojitá to extragear

[Christian Mollekopf]

On Wednesday 28 November 2012 00.27:04 Jan Kundrát wrote:
> On Tuesday, 27 November 2012 22:52:24 CEST, Christian Mollekopf wrote:
> > Sure, on the other hand the session does exactly that (as you
> > noted below) and is well separated from the parsing.
> 
> I disagree on the topic of separation -- if you take a look at fetchjob.cpp
> in particular, you'll see that the quote an amount of the actual parsing
> happens at the level of job, not earlier in the process.
> > I'm just wondering why you think it
> > wouldn't be possible to implement pipelining (relatively easily) in that
> > session, as that might be something I'd want to do eventually (as you
> > mentioned you got substantial performance improvements). So I'm
> > just trying to
> > learn from your experience here.
> > 
> > AFAIK pipelining is the following:
> > - You send a bunch of commands (which support pipelining),
> > without waiting for
> > a response
> > - You match the response to the sent command using the tag at
> > the beginning of
> > each command.
> 
> In IMAP, each command results in a response tagged with the same tag as you
> used in the command. So far, so good. However, plenty of command result in
> untagged responses as well, and as a bonus, servers are explicitly allowed
> to send untagged responses even without any command being in progress,
> completely on their own.
> 
> One possible solution to this is to work as Trojita does, i.e. start
> offering each received response to each active job, stopping as soon as a
> job declares the response as "handled". I cannot guess how much work that
> might involve.
> 
> In Trojita, we also have some auxiliary "jobs" (KeepMailboxOpenTask) which
> process any incoming responses containing mailbox updates. In fact, our
> equivalent of fetchjob.cpp does not handle FETCH responses at all -- the
> untagged FETCH responses are processed by the KeepMailboxOpenTask.cpp. This
> way, we don't care whether something like, say, a FETCH FLAGS is triggered
> by something on the server's side or as a result of an explicit FETCH
> command.

Ok, I can see the problem with untagged responses. Thanks for the explanation.

Cheers,
Christian

> 
> Hope this helps,
> Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20121128/51a66775/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/