On Sun, 2008-03-16 at 16:26 +0530, Samisa Abeysinghe wrote: > We have an efficient parsing mechanism already, tested and proven to > work, with 1.3. Why on earth are we discussing this over and over again? > > Does caching get affected by the mime parser logic? IMHO no. They are > two separate concerns, so ahy are we wasting time discussing parsing > while the problem at had is not parsing but caching?
No, the current implementation starts parsing after reading the whole stream. Because of that the parsing is simple and efficient. And for considerable size of large attachments(eg : 100MB) also it is working well. The only problem it has is the attachment size will depend on the available system memory. > Writing the partially passed buffer was a solution to caching. Do we > have any other alternatives? If so what, in short, what are they? We can keep current implementation and write the attachment to a file when it exceeds a certain threshold. This is inside mime_parser means at transport level. So we are not keeping the whole binary inside om_tree during the invocation of handlers and the receiver (may be the actual service or client) can straightaway access the file. Even though this approach will limit the attachment size we can handle to the system available memory , I think it has the added advantage of not keeping the attachment in memory. > > Samisa... > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
