On Wed, Feb 15, 2012, at 02:22 PM, Alexey Melnikov wrote:
> On 15/02/2012 14:19, Bron Gondwana wrote:
> > On Wed, Feb 15, 2012, at 02:11 PM, Tony Finch wrote:
> >> Is there any reason to keep subscriptions in IMAP 5 ?
> > I envisage "subscription" as either an annotation or a "Special Use" on
> > a folder rather than yet another axis of data.
> +1.
I was chatting to one of the other guys on our team yesterday about data
modelling in this context.
Mail is a structured data store, with some small set of types of data stored
in the IMAP "model". The IMAP protocol is very much about the communications,
and trying to optimise specific use cases.
But at the core, it's about querying and modifying data in a particular model,
with some constraints on the valid modifications - both for integrity and for
ACL permissions reasons.
Along with a side dose of syncronising up offline modifications to that same
data model.
This is not a problem that's unique to email. There's nothing really special
about email here unless you make it special. Sure there's a bunch of indexed
and optimised ways of viewing that data - sort by trimmed subject, encodings,
etc. All of which could be expressed as generic queries against the data
model with a query optimiser on the far end rather than needing a custom
syntax for everything...
It's a somewhat different view of email, but I think quite a useful perspective
to look at it from. Just a database with some funky constraints and triggers.
So in my head, I'm kind of thinking in SQL when I think about how I would
access email. LIMIT, OFFSET, ORDER BY, VIEW. Particularly VIEW and ORDER BY
with a dose of 'use modseq to re-synchronise up with your last copy of a view'.
CREATE VIEW 'Inbox' AS
SELECT * FROM Messages M JOIN Folders F USING (FolderId)
WHERE F.SpecialUse = '\Inbox' AND M.IsExpunged = 0 ORDER BY M.Uid DESC;
CREATE VIEW Status AS
SELECT FolderId, MAX(Uid) + 1 AS UIDNEXT, MAX(Modseq) AS HIGHESTMODSEQ,
COUNT(*) AS EXISTS, SUM(IsSeen) AS UNSEEN
FROM Messages WHERE IsExpunged = 0 GROUP BY FolderId;
There exist database engines which could optimise those views up the wazoo,
rather than writing a custom optimizer for each one, and a custom protocol
element with a custom parser for each value.
----
So basically what I'd like to see us doing with email is LESS. Less custom.
Less "it's so special". Treat it like a generic bunch of data, and manipulate
it with generic data manipulation methods.
Bron.
--
Bron Gondwana
[email protected]
_______________________________________________
imap5 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imap5
