I've got it working in my tree, but it required changing about half a dozen
delivery functions to carry a few more arguments. Ilja, do please push your
tree (with my patches ;-) into CVS, and I'll diff against it this evening.

Upon message delivery, both sizes are calculated and stored:
physmessage.messagesize = bytecount of header + bytecount of body
physmessage.rfcsize = bytecount of header + linecount of header
                      + bytecount of body + linecount of body

Aaron


"Aaron Stone" <[EMAIL PROTECTED]> said:

> So basically...
> 
> rfcsize = headersize + headerlines + messagesize + messagelines?
> 
> Aaron
> 
> 
> Roel Rozendaal - IC&S <[EMAIL PROTECTED]> said:
> 
> > on the rfc_size field:
> > 
> > the rfc_size is the size which should be returned when you ask the imap 
> > server to FETCH RFCSIZE. It differs from the messagesize because each 
> > of the newlines has to be counted twice as they are rewritten to '\r\n' 
> > when outputted by the imap server. Initially it is set to zero and the 
> > imap server updates this field the first time the rfcsize is requested 
> > (or, more precisely, the server updates this field if it is equal to 
> > zero) .
> > I came up with this when i observed frequent rfcsize requests from 
> > mailclients for the same mails, caching the rfcsize removes the need to 
> > parse the entire message time and time again.
> > If you feel like it, you can calculate this probably fairly easy when 
> > reading the data of the to-be-delivered message - that would be even 
> > better :-) (but i never found the time to do it :p)
> > 
> > regards roel
> > 
> > Op 26-feb-04 om 16:43 heeft Aaron Stone het volgende geschreven:
> > 
> > > I thought that there was a function that counted the final size of a 
> > > message
> > > automatically... but I guess not! In any event, I see that at the very 
> > > end of
> > > store_message_temp(), there's an update:
> > >
> > >   db_update_message(msgidnr, unique_id, totalmem+headersize, 0);
> > >
> > > The first problem is that the fourth argument, rfc_size, is 0. How 
> > > does the
> > > RFC size differ from the Message size? The second problem seems to be 
> > > that
> > > totalmem+headersize is not yielding a correct result. They are of 
> > > nominally
> > > different types, size_t and u64_t, but that should work, no?
> > >
> > > Aaron
> > >
> > >
> > > Ilja Booij <[EMAIL PROTECTED]> said:
> > >
> > >> Found the problem. Using the new delivery chain, the size of a message
> > >> is never stored, so the total size of the message (as stored in the
> > >> messagesize field in the physmessage table) is only the size of the 
> > >> header.
> > >>
> > >> Aaron, could you take a look at this? I guess the total size of the
> > >> message needs to be stored somewhere in the store_message_temp() 
> > >> function.
> > >>
> > >> I'll be off now, and won't be back until Monday. I want to release RC3
> > >> then. I hope we can tackle the Mozilla problem from then on (unless
> > >> anybody happens to find the cause of the problem before Monday :) ).
> > >>
> > >> Ilja
> > >>
> > >>
> > >> Ilja Booij wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> it seems that calculation of a user's mailbox size isn't working
> > >>> properly (not all messageblks are counted).
> > >>>
> > >>> I'm working on this :)
> > >>>
> > >>> Ilja
> > >>> _______________________________________________
> > >>> Dbmail-dev mailing list
> > >>> Dbmail-dev@dbmail.org
> > >>> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> > >> _______________________________________________
> > >> Dbmail-dev mailing list
> > >> Dbmail-dev@dbmail.org
> > >> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> > >>
> > >
> > >
> > >
> > > -- 
> > >
> > >
> > >
> > > _______________________________________________
> > > Dbmail-dev mailing list
> > > Dbmail-dev@dbmail.org
> > > http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> > >
> > 
> > _________________________
> > R.A. Rozendaal
> > IC&S
> > T: +31 30 63 55 736
> > F: +31 30 63 55 731
> > www.ic-s.nl
> > 
> > _______________________________________________
> > Dbmail-dev mailing list
> > Dbmail-dev@dbmail.org
> > http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> > 
> 
> 
> 
> -- 
> 
> 
> 
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> 



-- 



Reply via email to