* Re: NOV code in Gnus
[not found] ` <m2vg28vzni.fsf@tnuctip.rychter.com>
@ 2002-12-06 2:16 ` Paul Jarc
2002-12-06 13:41 ` Kai Großjohann
2002-12-28 18:38 ` Lars Magne Ingebrigtsen
2 siblings, 0 replies; 6+ messages in thread
From: Paul Jarc @ 2002-12-06 2:16 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: NOV code in Gnus
[not found] ` <m2vg28vzni.fsf@tnuctip.rychter.com>
2002-12-06 2:16 ` Paul Jarc
@ 2002-12-06 13:41 ` Kai Großjohann
2002-12-06 16:22 ` Kai Großjohann
2002-12-28 18:38 ` Lars Magne Ingebrigtsen
2 siblings, 1 reply; 6+ messages in thread
From: Kai Großjohann @ 2002-12-06 13:41 UTC (permalink / raw)
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)
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: NOV code in Gnus
2002-12-06 13:41 ` Kai Großjohann
@ 2002-12-06 16:22 ` Kai Großjohann
0 siblings, 0 replies; 6+ messages in thread
From: Kai Großjohann @ 2002-12-06 16:22 UTC (permalink / raw)
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)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: NOV code in Gnus
[not found] ` <m2vg28vzni.fsf@tnuctip.rychter.com>
2002-12-06 2:16 ` Paul Jarc
2002-12-06 13:41 ` Kai Großjohann
@ 2002-12-28 18:38 ` Lars Magne Ingebrigtsen
2 siblings, 0 replies; 6+ messages in thread
From: Lars Magne Ingebrigtsen @ 2002-12-28 18:38 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 6+ messages in thread