Re: A road map for Oort Gnus

[prj@po.cwru.edu (Paul Jarc)]

NAGY Andras <nagya@inf.elte.hu> writes:
> Consider the big Gnus<->backend interface redesign too, in order to be
> able to support `modern' backends with full functionality and good
> performance (yes, I mean IMAP).

Perspective of a backend author: I'd like to see an interface that
doesn't require backends to maintain state independently of Gnus.
E.g., nnchoke-open-server would be passed the full select method, and
would return one of:
(success server-object)
(transient-failure "Error message describing what failed")
(more-serious-failure "Error message describing what failed")
... where the server-object is opaque to Gnus and meaningful to the
backend, and is passed back to the backend functions for operations on
that server; the backend wouldn't need to have a notion of a
"currently active server".

Similarly for groups - nnchoke-request-{list,groups} would return an
alist whose keys are interned group names, and whose data are opaque
group objects.  Or maybe an obarray instead of an alist; I'm not sure
which would be faster most of the time.  The opaque group object would
be handed back to the backend functions (with its associated server)
for operations on that group.

All data should be passed back to Gnus through function return values,
not nntp-server-buffer.  Some backends will easily be able to
structure the data into, e.g., NOV vectors, so it won't have to be
dumped into text form just to be extracted back out again.  Other
backends will have NOV text to deal with, so they can use a common set
of NOV-text-parsing functions.  For example.

> - extend the interface to allow more complex `questions' to the
> backend (i.e. number of new messages, flagged messages etc, instead of
> the nntp-like low and high article number only)

Also, more complex actions, like "move/copy article 123 from group foo
to group bar".

> - let the backend store readness and other status settings, if it is
> able to,

This is already done...

> and do not redundantly store them in the frontend in this case.

... but this is not.

> - OTOH, let the backend to store certain backend-specific info in the
> frontend if it needs to

Each backend could maintain its own data on disk, independently of
Gnus and other backends, maybe.


paul