[spambayes-bugs] [ spambayes-Feature Requests-872051 ] Missing review items when using HTTP

[SourceForge.net]

Feature Requests item #872051, was opened at 2004-01-06 18:19
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=498106&aid=872051&group_id=61702

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pop3proxy
Group: None
Status: Open
Priority: 5
Submitted By: Brendon Whateley (brendonw)
>Assigned to: Tony Meyer (anadelonbrin)
Summary: Missing review items when using HTTP

Initial Comment:
When [html_ui] rows_per_section: is used to limit the 
number of rows displayed, the next/previous buttons still 
move in complete days, resulting in messages being not 
displayed. 
 
If this is not the desired behavior, assign this to me and I'll 
put a patch together. 
 
Brendon. 

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2005-05-30 19:01

Message:
Logged In: YES 
user_id=44345

It's been so long since I looked at the sb_server I no longer really know
where to look for the problem.  The ProxyUI._appendMessages method
seems to do the right thing (grab the first n rows).  My guess is the
"next" and "prev" links (wherever they are) need to be tweaked to not
jump day-by-day, but by chunks of n rows.  Not sure there that is
though.  Tossing back toward Tony on the outside chance this was
fixed long ago but never closed.  Tony, let me know where the next and
prev links are defined and I'll take another look.



----------------------------------------------------------------------

Comment By: Tony Meyer (anadelonbrin)
Date: 2004-11-02 21:18

Message:
Logged In: YES 
user_id=552329

No comments, but no patch...

If you'd still like this changed, then a patch would be
great <wink>.

----------------------------------------------------------------------

Comment By: Brendon Whateley (brendonw)
Date: 2004-01-11 00:12

Message:
Logged In: YES 
user_id=944315

Ok, I've thought about this a lot, and it seems like the semantics 
seem wrong.  The current option _claims_ to limit the maximum 
number of lines _per section_ which seems to make life much 
more difficult than it needs to be.  The primary reason for limiting 
the number of lines is to avoid very slow response times from 
the server.  When you add a limit on the number of lines, you 
don't also only want to display a single day at a time. 
 
A more natural approach would be to display messages for 
review _either_ per day OR per number of lines.  So, if you set 
the limit to 100 lines, you could page 100 messages at a time.  
This behavior would also be useful for reviewing a long history 
of messages that are sparsely populated in manageable 
groups, but faster than one day at a time. 
 
I'll wait a few days in case anybody has any comments before I 
implement something along these lines. 
 

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2004-01-07 15:06

Message:
Logged In: YES 
user_id=44345

Brendon,

A patch would be ideal.  My use case for the current behavior was 
that displaying either all pending messages or often just a day's 
worth can be hideously expensive.  I'd like to move by 
rows_per_section chunks through the pending messages, typically 
in chronological order.  You're more than welcome to implement 
other semantics though.  I don't actually use the pop3proxy these 
days, so my recollections about how it worked/should work may 
be off-base somewhat.

Since you're not a registered developer, I can't assign it back to 
you.  If you have a chance to create a patch though, just attach it 
and I'll review it for inclusion.

----------------------------------------------------------------------

Comment By: Tony Meyer (anadelonbrin)
Date: 2004-01-07 00:08

Message:
Logged In: YES 
user_id=552329

IIRC, Skip added this behaviour (or re-added it, maybe?).  I'm 
not sure what the correct behaviour is, so I'm assigning to 
him to make the call.  (I'm sure that if he does want it 
changed, he'll be happy for you to create a patch.  You can 
assign it back to me to check it in, if it gets to that).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=498106&aid=872051&group_id=61702