> However, the real issue is how are we going to implement "parse it for > MIME, and then cache it and move on". I still think that it is better to > stick to Thilina's viewpoint in having each attachment cached as a > separate file. And, each attachment should be cached, even if it is small > or large, when the content-length exceeds the threshold. What I proposed is not based on the content-length.. It's based on the size of a particular attachment. We calculate the size while parsing. If the size exceeds a certain limit then put everything to file.
Also you might want to consider deferred parsing of attachments. That means read the attachment for the stream only when needed. Similar in concept to StAX parsing of XML. >This is because > many small attachments == one big attachment. Good point.. thanks, Thilina >Thus, I'm still on the > parse_1st->cache_1st->parse_2nd->cache_2nd->... approach. I don't think > that a cache all at once will give us desirable results. > > > > >> > >>> 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. > >> > > > > How does this compare with what I proposed above in this reply? > > > > Samisa... > >> > >>> 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] > >> > >> > >> > >> > > > > > > -- > > Samisa Abeysinghe > > Software Architect; WSO2 Inc. > > > > http://www.wso2.com/ - "Oxygenating the Web Service Platform." > > > > > > > > --------------------------------------------------------------------- > > 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] > > -- Thilina Gunarathne - http://thilinag.blogspot.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
