Re: [SM-DEVEL] PHP imap_* function use

[Marc G. K. <ma...@it...>]

Jeff Bailey zei:

>>
>> It is unclear to me what capabilities are lost by not using them (I
>> mean, it all boils down to IMAP in the end anyway).  Indeed, I'd argue
>> that Squirrelmail gains the capability to do exactly what it needs to
>> against the IMAP server.
>>
>> But I have to agree about the performance issue, parsing responses in
>> PHP can be dog slow,  I believe this is optimizable however.
>
> Well I guess I was thinking more in terms of not re-inventing the wheel
> when I mentioned loss of capability.  I suppose I must agree that you
> could do whatever you want with the imap_stream in PHP, and suffer with
> the debugging of it.  I just discovered that the base64 decode in
> imap_print_body_lines is not very robust, it is broken for chunks not done
> modulo 4.  The imap_* library looks like a superior way to handle this
> task.
If you are a little bit patient our own imap-library will be superior because
it will support the whole scope of rfc2060 and a lot of imap-extensions.
imap_print_body_lines and all other currently used imap-functions will be
replaced.
The new under heavy development imap-implementation will be optimized for
speed on the parsing side and probably the most important thing, it will be
more efficient in the number of imap-calls needed for getting information.

On the memory-side everything will be more efficient because the concept of
the new imap-library makes use of "parse-on-the-fly" which means that every
line of output will be directly parsed and stored in the correct
arrays,objects depending on the received data.
The advantage is that we no longer need to buffer the entire output before we
start processing the result (like we do now).

Another feature that will be used for fetch responses regarding body-parts is
directly decode the data and directly do the charset conversion.

When that's all done we even might consider to rewrite the working php code to
make it work as a php-module. (personally I do not have experience with that)

In Squirrelmail the just described imap-library will be probably an extended
class of the message-class. That message class should work with other backends
too. Such backend could be a php-imap implementation. Personally I think that
the php-imap extension is not good enough and that our own implementation will
be better but I like to be surprised.

>
> So I really am more interested in the performance issue:  I think
> Squirrelmail is pretty cool but it could be so much better if it went
> faster.  A large number of e-mail messages (several hundred or more) makes
> Squirrelmail really drag its little squirrel feet.
100 % agreed. That's why we start on the development of the just described
imap-library.

For the interested people I placed a snapshot of the current imap-class on
http://www.its-projects.nl/imap/fetch.php
Be aware that the code contains experimental parts and also outdated parts
that need to be rewritten.
I estimate that 60% of the work is done.

Regards,


Marc Groot Koerkamp.


-----------------------------------------
International Tender Services (ITS) B.V.
Burg. Kerssemakersstraat 32-b
8101 AN Raalte
Tel.nr.: 0572-362240
Faxnr.: 0572-362245


***************************disclaimer***************************

De informatie verzonden met dit e-mailbericht is uitsluitend bestemd voor de geadresseerde. Gebruik van deze informatie door anderen dan de geadresseerde is verboden. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van deze informatie aan derden is niet toegestaan. International Tender Services (ITS) B.V. staat niet in voor de juiste en volledige overbrenging van de inhoud van een verzonden e-mail, noch voor tijdige ontvangst daarvan. International Tender Services (ITS) B.V. attendeert erop dat de vertrouwelijkheid van informatie verzonden per e-mail niet gewaarborgd is.