>> 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.
Ideally it should be either the Content-Length or if Chunked then we'll have to read until the end of chunks. So, if you see Content-Length, then no need to calculate size while parsing. You already know it. But, your proposal is valid for the Chunked case. > > 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. That will cause the stream to exhaust for the lifetime of the request isn't it? If not can you explain the procedure? Regards, Senaka > >>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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
