select response.
* Tried to fix the broken del move next function and added a few arguments
to the dmn_expunge function because the globals scared me when I couldn't
get the job done.
decoding because otherwise we have to buffer entire attachments in memory
which will cause out of memory errors with large attachments.
The fix has to do with the grouping of bytes in pairs of 4 which represents
24 bits of data. If such group is splitted over 2 lines then on the fly
decoding went wrong. Now we count the pure base64 data (without \r\n, \r \n
and spaces), divide it by 4 and return incomplete pairs which get processed
the in the next loop.
Correct some mistakes (compose_in_new, resume draft, edit as new)
Centralize javascript detection in prefs.php - checkForJavascript
Move javascript_on from prefs to session - have just javascript_setting in prefs.
sqimap_create_stream() was not as generalized as it should have been - it was still using $imap_server and $use_imap_tls, etc. Now obeying passed params as it should.
draft-siemborski-imap-sasl-initial-response-01b.txt to SASL-IR (imho a
better name). Currently Cyrus 2.2.2-BETA advertise SASL-IR and the next UW
release will do that too.
Added basic @package/@subpackage tags
The decode/ files were documented slightly more thoroughly, although they're almost self-explanatory anyway.
The individual functions in the functions/ files need to be documented though, and now that this commit is in, anyone willing to write docblocks for functions should get cracking ;)
was a good moment to implement the SASL imap extension.
See also <draft-siemborski-imap-sasl-initial-response-00.txt>
NB: The code is untested and I like to know if it works. Volunteers to test
(Rob Siemborski maybe) ?
The fread behaviour was changed with as result that fread didn't return
when the requested buffersize was full but at a earlier stage, at the end of
a tcp packet.
From now on fread stops on: EOF, full buffer and in case of sockets at end
of packet if the imap server isn't providing the requested data quick
enough.
buffersizes anymore because we cannot trust fread if the requested buffer is
actually returned.
blocking socket connections do not work anymore like they supposed to work
:(
have "proper" lines with the same length. With an old uw server I discovered
that lines were split in the middle by \n. This fix will correct it.
The rfc about base64 decoding does not mention anything about line length.
rfc2045 does mention that lines should not be longer then 78 characters but
does not say all the lines (excluding the last of course) must be of the same
size.
There for i could not ignore it and fixed it.
mistake from me. I didn't ended the query with \r\n but ended it with \n. I
should have known better.
An interesting discovery was that setting the number of queries to process
at once influence performance. A higher number doesn't mean more performance.
In our tests 128 was slower then 32 (on Exchange 2000).
out of order reponses. Now it works.
In imap_mailbox te array with mailbox objects wasn't create correctly. It
contained double entries. That's fixed too.
in parts. Now we do a request for 32 queries and retrieve the response
before we continue with the next 32 queries.
The number 32 is experimental and should be tested on Exchange 2000 because
that was the imap-server which drops the connection with 100 calls at once.
Maybe we should lower it or raise it.
before echo it to stdout. with fread we detect how long the base64 encoded
liones are so we can do base64 decoding on the fly.
The advantage of using fread instead of fgets is that the buffersize can be
used so we reduce the number of echo calls (fread doesn't stop at \n).
