Hello, On Wed, 23 Jul 2008, Andreas Schamberger wrote:
> Before I get to some problems I had with the MIME code in ezcMail I want > to raise an important question: How do we solve the problem that we > don't rely on other components and don't want to duplicate code either? > By not adding a SOAP component with MIME support? ;) Any comments? We'd need to split out the MIME handling support into perhaps it's own component. I don't know how feasible that is -- I've little idea on how SOAP deals with MIME as well - would you have a link to some summarized information? > Generally speaking it was quite easy to (ab)use the MIME handling for my > purpose, but I had some troubles with the MIME classes: > > a) ezcMailMultipart::$noMIMEMessage has some text to inform mail clients > without MIME support about this problem. It is not possible to disable > this and therefore I also had these messages in my SOAP messages. In my > case it didn't cause any problems with the server (connecting to > amazon), but it definitely shouldn't be there. > Can we add an option to disable this? Yes, sure. Please file a feature request for it. With patch and tests would be even better :) > b) ezcMailVirtualFile (all ezcMailFile classes I think) has a fixed > encoding (base64) and it is not possible to change it. Why is the > encoding fixed? In other parts of the MIME code one can configure that > (e.g. ezcMailText)? Therefore I had to extend the class to get the > required 8-bit for my XML attachments. Which other encodings would you want? Quoted-printable doesn't really work so well for 8-bit files. And it's also not safe to put raw 8-bit data into either e-mail or XML as far as I know. > c) When parsing a MIME message the detected files are saved to a > temporary file on disk. Why? To save memory resources. You can't really expect mail to not come with 50mb attachments - which would quickly fill up the memory. > For the SOAP component this is unnecessary overhead as I want to > inject the data into the result XML of the SOAP request afterwards. An > option to use ezcMailVirtualFile (instead of ezcMailFile) as target > would be cool. I think that would be useful to have as well - as an option. I think we already allow setting some overrides for class names (through http://ezcomponents.org/docs/api/latest/Mail/ezcMailParserOptions.html), so adding another similar option would be great to have. Again, a feature request and/or patches with tests would be useful :) > Ok, that's it for now. If you finally don't remember what this > confusingly written mail is all about: > - possible new ezcSoap component I've a question for you here as well - would this sit on top of PHP's SOAP extension, or something totally new? I'd prefer it actually if some of this works went into improving the SOAP extension instead if necessary and useful. regards, Derick -- Derick Rethans eZ components Product Manager eZ systems | http://ez.no -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
