Senaka Fernando wrote:
Manjula Peiris wrote:
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.
Still, my argument on the separation of concerns on caching vs. parsing
holds.
It is a question about what takes precedence over the other. If the
attachment is too large, we need to interleave the concepts, where you
read a considerable amount that is ideal in size in terms of caching,
parse it for MIME, and then cache it and move on.
Parsing will always be choice No. 1. We cache only if we can't handle it.
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. This is because
many small attachments == one big attachment. 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.
I do not think you seem to understand what I am talking about. Seperate
attachments do need to go to seperate files. There is no question about
that. The queestion here is not about multiple attachments. The
question is about "very large attachment".
Samisa...
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
