Re: overview -> .db files?

[kai.grossjohann@uni-duisburg.de (Kai Großjohann)]

Wes Hardaker <wes@hardakers.net> writes:

>>>>>> On Thu, 31 Oct 2002 19:21:44 +0100, kai.grossjohann@uni-duisburg.de (Kai Großjohann) said:
>
> Kai> But I think there are already provisions for using headers
> Kai> instead of NOV format.  So maybe that's a spot where you can hook
> Kai> in and return the headers to Gnus in a Lisp data structure
> Kai> without going via a buffer.
>
> Yeah, I realized it would likely affect both the place where Gnus and
> the backends were involved.  Essentially functions would have to wrap
> access to NOV calls, and what the NOV calls did behind the scenes
> would either look stuff up in a list (as is now) or in a DB.

Ah, you had in mind the *right* solution :-)

> Kai> It would be a major undertaking.  Please work on it :-)
>
> Doubtful.  I suspect it'd be a bit over my head with respect to gnus
> code.  I'm sure I could do it, but the undertaking would be even
> larger for me ;-)

Not all of us can be expected to be gurus like Lars and ShengHuo :-)
I admire those who grok the Gnus code.

> Kai> Another possibility which might be easier is to keep the backend
> Kai> interface and to just use the db files as a faster way to extract
> Kai> the right headers.
>
> Yeah, I thought of that as well.  Actually, just making the overview
> files be .el files would probably be a big win.

Indeed.  Ah, that could be a first step.

I don't know, however, if Gnus sometimes looks at parts of the
overview file only.

> Kai> At least for me, the slow part about using Gnus is the generation of
> Kai> the summary buffer.  I wonder if that can be made faster somehow.
>
> Yeah.  The patch I wrote a while ago to display the summary buffer as
> it's building it is a good thing, because it lets you view stuff to at
> least keep you occupied while it's building.
>
> (I've been bugging my boss about his half of the assignment rights for
> it as well as the nnsf code, but he's a busy guy)

Oh yes, I think I wanted to install that.

> Kai> Is there a way to create a buffer with a lot of text properties and
> Kai> stuff really quickly?  What happens if we princ (buffer-string) to a
> Kai> file and then read that representation into memory and use a single
> Kai> insert call to create a buffer from it?
>
> That's worth trying.
>
> I've often thought that on exiting a summary buffer, you have all the
> display information since you've already created it, so couldn't we
> save the current buffer to a file, reload it and reapply all the
> regions and insert new contents?  That *may* be faster than rebuilding
> it from scratch every time.

Yes, inserting the new information might be possible if you look at
how `/ N' and `/ O' do it.

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