Re: [Pan-users] Suggestion, re large groups

[Nathan Morell]

Nathan Morell wrote:
> ya, only sounds like 30 lines or so :P
> hahah, ya sounds great to me. But like a helluva lot of work
>
> Charles Kerr wrote:
>
> > On Wed, Jul 02, 2003 at 11:53:22PM -0400, Johan Ovlinger wrote:
> >
> >  
> >
> > > People (myself among them) have lamented the horrible performance of 
> > > the gtk2
> > > widgets when faced with 10k item lists.  Not much pan can do about that,
> > > without getting hands very dirty in toolkit internals.  But we can 
> > > shorten the
> > > lists:  I was thinking that most groups that have such large numbers 
> > > of items
> > > will be binary groups, with multi-multi-part posts.  Pan already 
> > > combines
> > > multipart posts: why not automatically thread multi-multi-parts?
> > >
> > > huh? whadaya think? huh? huh?   
> >
> >
> > I think a patch would be welcomed. ;)
> >
> >
> > _______________________________________________

I was thinking about this, wouldn't that mean you'd have to create a new 
 entry into your sql database, and link that entry to all the articles 
it pertains to.
ie:

First Header in Multi-part binary -> Header / Body [1/5]
                                 -> Header / Body [2/5]
                                 -> Header / Body [3/5]
etc.

and that would mean only the First header is displayed, and thus we are 
not loading 400k headers, but rather.. 500-600 or so. I was also 
thinking we'd have to keep a hash table of these, and if the multi-part 
binary is not complete.. it wouldn't do us any good. So it would prolly 
only work for complete multi-part binaries. And that sounds like a pain 
in the ass.. You'd have to compare your Hash table every time the 
headers were updated, and check to see if your hash table is still 
correct. There might be ways around that for all I know. Maybe another 
table sql table just for the hash table, and lets just assume the table 
is correct so that we don't compare it to the entire header list. This 
way, when we update the expired articles, we just check those expired 
articles for there corresponding hash table entries.

anyway, is all of this sounding feasible? I'm trying to think of ways to 
work within the bounds of gtk2, considering a rewrite of the interface 
would prolly be a pain.

--Nathan