Gnus development mailing list
 help / color / mirror / Atom feed
From: Steinar Bang <sb@dod.no>
To: ding@gnus.org
Subject: Re: Re-imagining Gnus as a mail reader
Date: Sun, 02 Jan 2011 18:17:57 +0100	[thread overview]
Message-ID: <87zkrj8bsq.fsf@dod.no> (raw)
In-Reply-To: <m3pqszlsgw.fsf@quimbies.gnus.org>

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> But now I'm kinda wondering how Gnus would have looked if it had
> modelled itself on IMAP instead of NNTP.  IMAP is (sort of) a superset
> of NNTP, but not quite.  Perhaps the main difference is that IMAP is
> slightly more explicit about the trifurcation between
> unread/read/non-existent, while NNTP only (sort of) has "some articles
> exist in this range".

One more thing to think about if re-imagining the backend interface
around IMAP: MIME awareness (specifically accessing parts of a message)

And a reimaginging should probably consider agent-like functionality
from the start, rather than as an afterthought.

Desirable agent-ish functionality:
 - Offline reading and responding/forwarding/resend (setting marks
   "upstream" when going offline)
 - Offline delete/copy/move (copy and move should work across servers,
   but it should be able to do them cheaply when eg. moving on an IMAP
   server)
 - Offline expiry
 - Agent synced with upstream changes when going online (could be an
   awful lot of talking when the agent has many articles, the server has
   many articles etc.)
 - MIME awareness (partial dowloads)
 - Minimize network traffic (ideally each message part should only cross
   the wire once, cross server copies/moves excepted)

Another point of consideration: should the agent be another backend like
the others?  Could being an agent be a property of the backend
interface?  Ie. any backend could be an agent for any other (and you
could eg. use an IMAP server as an agent for NNTP if that's your fancy)?

If so, the agent could just be good old nnml, or whatever is the most
efficient local mail backend these days...?

Possible ways of wiring the backend and the agent together:
 - Letting the actual backend own the agent backend and use it for local
   storage 
 - Letting the agent be in front of the actual backend.  Ie. the user
   will always be talking to the agent

I think if I was implementing it, I would prefer the latter alternative,
based on nothing more scentific than "it feels right".




      parent reply	other threads:[~2011-01-02 17:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-18  2:34 Lars Magne Ingebrigtsen
2010-12-18 14:13 ` Ted Zlatanov
2010-12-18 15:18   ` Julien Danjou
2010-12-18 15:37     ` Ted Zlatanov
2010-12-18 21:38       ` Julien Danjou
2010-12-18 18:47   ` Lars Magne Ingebrigtsen
2010-12-19 14:15     ` Ted Zlatanov
2011-01-02 17:17 ` Steinar Bang [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zkrj8bsq.fsf@dod.no \
    --to=sb@dod.no \
    --cc=ding@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).