PEAR's Mime packages development currently looks stopped. My proposition is to create our own classes, of course by copy&paste from them, but this is needed if we want to fix following issues:
- non-ascii attachment names (basename's utf issue)
- big memory consumption of attachments handling
- rfc2047 for name, rfc2231 for filename
- internationalised domain names
- other that I forgot
I volunteer to do that switch.
hello alec,
A.L.E.C wrote:
PEAR's Mime packages development currently looks stopped. My proposition is to create our own classes, of course by copy&paste from them, but this is needed if we want to fix following issues:
- non-ascii attachment names (basename's utf issue)
- big memory consumption of attachments handling
- rfc2047 for name, rfc2231 for filename
- internationalised domain names
- other that I forgot
I volunteer to do that switch.
why don't you/we/whoever takeover the pear::mime maintenance? by doing so, more people would profit and there would be no need to reinvent the weel, c/p or fork.
cheers, raoul
On Mon, Sep 22, 2008 at 10:42 AM, Raoul Bhatia [IPAX] r.bhatia@ipax.at wrote:
hello alec,
A.L.E.C wrote:
PEAR's Mime packages development currently looks stopped. My proposition is to create our own classes, of course by copy&paste from them, but this is needed if we want to fix following issues:
- non-ascii attachment names (basename's utf issue)
- big memory consumption of attachments handling
- rfc2047 for name, rfc2231 for filename
- internationalised domain names
- other that I forgot
I volunteer to do that switch.
why don't you/we/whoever takeover the pear::mime maintenance? by doing so, more people would profit and there would be no need to reinvent the weel, c/p or fork.
I agree, Alec if you are interested in it. I can help you with the process and mentor you. ;)
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
till wrote:
why don't you/we/whoever takeover the pear::mime maintenance? by doing so, more people would profit and there would be no need to reinvent the weel, c/p or fork
I agree, Alec if you are interested in it. I can help you with the process and mentor you. ;)
I'm not sure if I'll have time to play with PEAR. Just want to fix roundcube issues. Another solution is to leave those classes where they are, modify them in roundcube repository and send patches to PEAR's bugtracker. But doing this without care of php4 support, backward compat. and compatybility with other PEAR classes would be just more simple.
On Mon, Sep 22, 2008 at 2:05 PM, A.L.E.C alec@alec.pl wrote:
till wrote:
why don't you/we/whoever takeover the pear::mime maintenance? by doing so, more people would profit and there would be no need to reinvent the weel, c/p or fork
I agree, Alec if you are interested in it. I can help you with the process and mentor you. ;)
I'm not sure if I'll have time to play with PEAR. Just want to fix roundcube issues. Another solution is to leave those classes where they are, modify them in roundcube repository and send patches to PEAR's bugtracker. But doing this without care of php4 support, backward compat. and compatybility with other PEAR classes would be just more simple.
If you submit your patches to PEAR bugtracker, I can take care of them.
The only thing you should keep in mind is to not use RC code in your patches. Then it should be easy to put them in. I can if necessary work on PHP4 compat and all that.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
A.L.E.C wrote:
PEAR's Mime packages development currently looks stopped. My proposition is to create our own classes, of course by copy&paste from them, but this is needed if we want to fix following issues:
- non-ascii attachment names (basename's utf issue)
- big memory consumption of attachments handling
- rfc2047 for name, rfc2231 for filename
- internationalised domain names
- other that I forgot
Maybe it's time to take a deeper look into SwiftMailer [1]. On the rist sight this package seems to solve many of your issues including reading from files/streams and therefore consuming less memory. I don't know about the non-ascii attachment names. It also supports plenty of APIs to deliver a message.
~Thomas
[1] http://www.swiftmailer.org/
List info: http://lists.roundcube.net/dev/
-
A.L.E.C -
Raoul Bhatia [IPAX] -
Thomas Bruederli -
till