Re: NOV code in Gnus

Re: NOV code in Gnus

[Paul Jarc]

Jan Rychter <jan@rychter.com> wrote:
> It turned out not to be so simple. I expected to find an interface to
> NOV data somewhere in nnheader.el. To my surprise, there is no unified
> interface to NOV data in Gnus and the code for NOV processing seems to
> be scattered around multiple files.

What sort of interface are you looking for, exactly?  Do you know
about nnheader-parse-head, nnheader-parse-nov, and
nn*-retrieve-headers?

> Some if it is duplicated, as well, it seems that at least nnmaildir
> chose to reimplement most of it completely.

nnmaildir does lots of things differently.


paul

Re: NOV code in Gnus

[Paul Jarc]

Jan Rychter <jan@rychter.com> wrote:
> Say I'd like to provide another implementation for storing NOV data.

So that you could, e.g, use nnml as your mail backend, but make it
store NOV data differently than it does now, is that right?

> there are many functions that assume that it's just going to be text
> files.

"Assume" suggests that it would make sense for a user to try to use a
different format, and that the code is at fault if it can't deal with
that.  I'm not aware of any assumptions in that sense; the backends
aren't designed to accommodate that use, and the user is at fault if
they try it.  That said, it might be nice if the design were changed.
I don't know whether it would really be worthwhile, though.  Maybe.


paul

Re: NOV code in Gnus

[Kai Großjohann]

Jan Rychter <jan@rychter.com> writes:

> So, I'm thinking about a unified interface for storing and accessing NOV
> data.

Yes.  I think it might be quite a lot of work.  Internally, Gnus is
divided into something that we might call a frontend and the
backends (ie, nnml, nnfolder, nnimap, nnmaildir, ...).  Gnus defines
a so-called backend interface.

When you enter a group, for building the summary buffer the frontend
requests the necessary data from the backend.  The data is passed
through a buffer.  The format of the buffer needs to be either NOV, or
it needs to be a sequence of RFC-822-style message headers.  (I'm not
sure about the separation between the headers for two messages in the
second case.)

I think it might be useful to augment the frontend/backend interface
in such a way that Lisp data is passed instead of buffer contents.

If you don't want to change the backend interface, then your best bet
is to transmogrify the information into NOV format.  That is likely to
be a performance hit over just inserting some file contents...

But I haven't tried it so maybe it would work to generate the NOV
from, say, an SQL data base on the fly.

-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: NOV code in Gnus

[Kai Großjohann]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

> Jan Rychter <jan@rychter.com> writes:
>
>> So, I'm thinking about a unified interface for storing and accessing NOV
>> data.
>
> Yes.  I think it might be quite a lot of work.

Actually, what you suggest is a useful first step in the direction I
was outlining, and it would be useful in its own right, so why not go
ahead and do it...

I'm always angry at people who say ``if you do A it would be useful
to do B, too, and B is a lot of work, so just don't bother''.  I
really *hate* that.  And now I just said it myself!  I'm sorry.

*blush*
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: NOV code in Gnus

[Lars Magne Ingebrigtsen]

Jan Rychter <jan@rychter.com> writes:

> Ah, yes, my description wasn't very good. I was thinking about something
> the other way around. Say I'd like to provide another implementation for
> storing NOV data. There seems to be no easy way to do this, as the
> knowledge about the implementation of NOV storage is scattered around,
> and there are many functions that assume that it's just going to be text
> files.

Well, that is what NOV files are, isn't it?  :-)

But, yes, the NOV parsing/generating code is somewhat confused, both
for hysterical reasons and for reasons of efficiency.  For instance,
`nnheader-parse-overview-file' just, well, parses a NOV file, while
`gnus-get-newsgroup-headers-xover' parses a NOV file while doing
threading, gathering, washing and making a nice 5-course meal for the
entire family.

> So, I'm thinking about a unified interface for storing and accessing NOV
> data.

The actual number of places that NOV files are stored/accessed is
also quite large, but most of them use the nnheader functions for
generating/parsing the files.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: NOV code in Gnus

[Kai Großjohann]

Jan Rychter <jan@rychter.com> writes:

> Are there plans to merge the various pieces of code together into a
> single interface? I'd imagine something along the lines of a unified
> interface that various backends could reimplement to their liking, if
> necessary.

This sounds like a great plan.  Actually, it occurred to me, too, the
other day, while I was taking a shower...

But I think that nnmaildir does it differently than the other
packages.
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)