Re: [Evolution-hackers] Newsgroup lists



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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]