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
