> Senaka Fernando wrote: >> Hi Samisa, >> >> IIRC, this discussion is on handling attachments and thus, does not >> relate >> to caching. Though $subject says "Caching" what actually was discussed >> was >> a mechanism to buffer the attachment in a file, rather than in memory, >> and >> that buffer has nothing to do with a Caching, which is a totally >> different >> concept, as in [1]. >> > > If you look at Axis2/Java caching really means what we discussed, and > not [1]. In other words the context is different.
Yes, and also thinking about [1], it is actually a implementor's choice rather, just the same as session. WS Specs do not demand such native support for either a SOAP or REST engine. Thus, IMHO, even in the long run [1] will not be needed. > >> The previous mail I sent was a reply to Manjula's concern in handling a >> scenario where the MIME boundary appears as two parts distributed among >> two reads. As unlike the previous scenarios, the once read block will be >> flushed to a file, instead of having it in memory. Thus, parsing may >> have >> to be thought of. Sorry if it confused you. >> >> IMHO, writing a partially parsed buffer to a file is not that efficient >> as >> we will have to parse it sometime later, to discover MIME Boundaries and >> extract attachments. Thus, I still believe that realtime buffering to a >> file while parsing is still a better choice. To implement such, we will >> have to modify our mime_parser.c, and probably the data_handler >> implementation. >> > > That bit needs to be rationalized when implementing the caching, on top > of current parser logic. +1, Regards, Senaka > > 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]
