Re: [Evolution-hackers] Newsgroup lists

[Not Zed <notzed ximian com>]

On Tue, 2003-12-02 at 04:10, Meilof wrote:
> Hello,
>
> I'm working on NNTP support in Evolution, particularly the subscription 
> interface currently, but I've encountered some problems.
>
> First, I've written the code that contact the news server for a list of 
> newsgroups by implementing nntp_store_get_folder_info using the code 
> from camel-nntp-grouplist.c. For my test news server, which has

No this is completely wrong, you should be using the existing code already in camel-nntp-store.c, which already implemenets list (but not subscribe).  Subscribe should just be implemented in-memory by using/subclassing camel-store-info class.

The old code doesn't use the camel-nntp-stream, but you need ot use that, and camel-nntp-store.c uses it.

camel-nntp-grouplist isn't useful for anything but reference.

> something like 5 newsgroups, this works pretty well, and the groups show 
> up nicely in the subscription dialog, but for the news server of my ISP, 
> which has _much_ more groups, I find the subscription dialog to be way 
> too slow. After the nntp_store_get_folder_info code has returned, and 
> the complete newsgroup list is in, on my PC, a 2GHZ box, it still takes 
> the dialog about five *minutes* to finally display the information, time 
> during which Evolution totally locks up (apart from also consuming a 
> huge amount of memory).
How long is the list?  GtkTreeView can bog down on big lists, i'm not sure what else would cause a real slowdown, perhaps the subscribe dialogue does some iterative things.

Also, you need to save the list, so you don't have to get it every time.

> Maybe the best approach would be not to show all groups at once, but to 
> have a search dialog box or a tree structure or something, or the 
> subscription dialog should be optimized to be able to handle large 
> amounts of folders. Are there any easy solutions for this?
Split it as a tree.  i.e. use .'s as dir separators

> Another thing: quickly looking at em-subscribe-editor.c, I found there 
> is no difference between the initial loading of the folder list and 
> subsequent loadings with the "Reload" button from the subscription 
> dialog. For news servers that don't support the NEWGROUPS and DATE 
> command, this would mean every time the dialog pops up, the complete 
> newsgroup list needs to be loaded, which might get a little irritating

> after a while, especially if it remains this slow. Do you think this is 
> acceptable, or should I look whether I can do anything about it?
You have to cache everything to disk (by storing it in camel-store-info and saving/resotring that from disk), and just use the NEWGROUPS command when you do a list, rather than doing a LIST every time.