FOSDEM Report - Saturday

[Alexey Melnikov]

On 08/02/2012 04:08, Greg Banks wrote:
> G'day,
>
> Sounds like you're having fun at FOSDEM :)
>
> On Tue, Feb 7, 2012, at 02:27 PM, Bron Gondwana wrote:
>> (I'm copying this to the cyrus-devel list because it's of interest
>>   to Cyrus people too...)
> I'm replying here on the same principle.
Likewise.

[...]
>> - Bugzilla - use it for everything.  If it doesn't have a bug number
>> where
>>    discussion took place, it doesn't get accepted.  This is a major
>>    workflow
>>    change, and is probably more of a challenge for me than anyone else.
> Sounds good.
>
> Another thing I'd like to see is a push hook on git.cyrusimap.org's master and 2.4 branches, so that if a git commit has the text "Bug NNNN" in the subject then the commit message is copied to Bugzilla and the bug marked RESOLVED - FIXED.
That would be great.
  [...]
> NSpam Reporting via IMAP:
>
> - Alexey mentioned that there's talk of adding a command to IMAP to
> report
>    a message as spam/non-spam rather than setting flags.  This would be
>    used
>    to actually take action based on the report.
> - Google and Yahoo are both involved in this effort.
An early draft on the topic:
<http://datatracker.ietf.org/doc/draft-ordogh-spam-reporting-using-imap/>

Note that it is very likely to change, I've sent lots of details 
comments to the editor already.

The document is currently being discussed on:

<http://www.ietf.org/mail-archive/web/apps-discuss/current/maillist.html>


> Sounds interesting, any more information?
>
>> Mail Protocol - initial notes: (Timo&  Bron)
>> ==============================
  [...]
>> - GUIDs for Folders as well, detect renames.  Dovecot and Cyrus both keep
>>    a GUID for each folder internally.
> Yes!
Sounds sensible. This should be another spec.
>> - MSGNO/UID/Uidvalidity/etc?  What do we need to keep?  Ordering
>> properties
>>    are nice.
> MSGNO is a completely useless historical artifact that should be buried in lye and forgotten.
No, it is actually very useful if one wants to implement an online 
client (as opposed to disconnected client).
> We need a stable identifier for each message, preferably one which is truly stable, i.e. doesn't change on reconstruct or replication.
Yes.
> UID+UIDVALIDITY is a sad approximation to this.  RFC822 Message-Id is a better approximation, except for Drafts and other Message-Id-less messages.
Except that Message-Id doesn't work for duplicated but not identical 
messages, etc. It is better do something like UID+UIDVALIDITY.
>>    Definitely 64 bit everything.
> Yes!
>
>> - single modseq counter per user?  What about shared folders.  Need to
>> get
>>    some statistics.
>>
>> WISHLIST:
>> - simple enough that what client authors "expect" just works.  If they
>>    get confused, it's our fault.
>> - UTF8 everything.
> Yes!  And no quoting crud either.  All strings are non-synchronising literals in UTF-8, except raw message data and annotation data which is binary non-synchronising literals.
I have sympathy to this argument. Getting rid of quoted strings would be 
fine.
I do however think that having some mechanism for a server to refuse to 
accept a literal before the whole thing is received (in case it is big) 
would be good. Dropping connection in such cases is not nice for clients.
>> * Batching / pipelines.  SEARCH + MARK FLAGGED + MOVE TO ANOTHER MAILBOX
>>    - basically, "lego blocks" vs "pre-defined"
>>    - leads on to;
> OMG, it's NFSv4 all over again.  The horror.
Well, some simple cases are addressed with SEARCHRES and it works really 
well.
>> * Question: do we want full transactional semantics?
> No.  Transaction boundaries are impossible to get completely right, and it's hard to implement and test and scale.
Agreed. This is very hard for servers to implement and I haven't seen 
requests from clients for this anyway.
>> Stateless Operation:
>> * Phones / poorly connected devices
>> * Power usage considerations.
> Yes!
>
>> Notifications:
>> * Able to easily receive notifications about ALL changes of interest,
>>    emails / folders / whatever.
Bron's idea about globally unique modseqs sounds interesting. Otherwise 
use IMAP NOTIFY.
>> * Notifications still work if connection disconnected (see above)
>> * Compatible with out-of-band notification to do cheap resync (use OS
>>    remote notification system in case of phone, etc) - if present.  Even
>>    SMS.
> Yes!  ...somehow.
>
>> A lot of these is the CISC vs RISC debate.  I believe it's better to
>> compose your messages from client to server and server to client out
>> of groups of small "lego bricks" each of which expresses one thing
>> succinctly rather than pre-formed "fighter wing" shapes.
> Yeah sure, this seems like a good idea now, but further down this track you will end up sending little bytecode programs from the client to the server for every operation like NFSv4 does.  This actually makes both clients and servers harder to write test and debug.  And, like Lego, everything you want to do is not quite the right shape and doesn't hang together properly.
You have a point :-)

Best Regards,
Alexey