Re: [Evolution-hackers] initial NNTP patch

On Wed, 2003-12-10 at 03:23, Meilof wrote:
Not Zed wrote:

> But could you re-do the patch using -u3 to diff?  Patch isn't liking 
> it and not applying it automatically.  I'd like to apply it and give 
> it a test!

I have done a unified patch now:
Cool thanks, i'll check it out shortly!

> (actually that whole method heir_find_folder is questionable, should 
> probably use a hashtable, a linear search will get slow with a big 
> list like a newgroup list).

hier_find_folder is used on the list of folders that is being returned 
by the get_folder_info list, so usually this will not be a really large 
list (given that get_folder_info is called recursively only in 
'subscribed' mode). I had to store this in a pointer array to be able to 
sort the list, which is not directly possible on the structure 
get_folder_info returns.

Sorting is fair, but you should use a hashtable for the lookup.  It makes the code simpler anyway (no need for that funjction at all).

> Won't it just take a lot of time anyway?  It could be a long list.  If 
> you have a tree view (like in the subscribe dialogue), then you could 
> list more incrementally (i can't remember, you can do a list of alt.% 
> or something to get a given level without having to get everything?).

The subscription code in em-subscribe-dialog _does_ an incremental list, 
but once it has all root folders, it will start by finding the 
subfolders of 'aaaa', 'aaab', etc, and there is no way to make it do 'z' 
before that. If you can make it do 'z' faster, then it is really fast 
enough I think...
Actually em-subscribe-dialog doesn't go in fully linear order.  It will scan from the top to find out if a folder has subdirectories.  Once it knows it has it adds them.  If you then open one of those, it will put all of its children ot the head of the scan list - so if you're going down the tree step at a time, it'll prioritise those.  The problem is of course is that if any level is very long, then you will have to wait for that level to be processed first.  If em-subscribe-dialog kept track of which part of the list you are viewing at the time, it could further prioritise the scan though - be pretty easy too i think.

> I guess it would make sense to always do the latter for the 
> subscription dialogue, and have it optional for the frontend, but the 
> api doesn't really cater for alternatives since they both go through 
> the same interface.

Hmmm... I personally wouldn't want a hierarchy in the main window, but I 
can implement it anyway. So this should be a NNTP configuration setting 
as well?
So what you're doing is:
flat when asked for subscribed
heirachy when asked for all

Yeah i dunno whether it's really that useful a feature, but *shrug*, it was just an idea.  Its open to discussion as to whether it should be added.

The config option would probably just change get_folder_info(SUBSCRIBED) to return a heirarchy rather than a flat list - if its a huge amount of work i wouldn't put too high a priority on it.


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