Hi Thilina,
I agree that buffering the actual SOAP message body text in the case of
attachments is fine, at least until we see some reason to change. If
somebody's using attachments hopefully the SOAP message body is not
going to be huge and buffering it will not add a lot of overhead. The
actual attachments should not be buffered unless necessary, though (as
when the user is accessing them out of order). If the user accesses the
attachments in order there should be no need for buffering these.
There should also be no need for buffering attachments on output, in
general. Some forms of output need to know the size of the data, so for
these the attachment API should provide a way of getting that
information without reading and buffering all the attachment data. If
the source of the attachment data doesn't know the size, and this
information is needed, buffering would still be required.
- Dennis
Thilina Gunarathne wrote:
Hi,
I'm thinking of Buffering the stream containing the SOAP envelope only
when someone actually refering to the attachment..
While that's interesting in theory, whoever sent the attachment more
often than not expected the other end to read the darn thing. I don't
see the point of that potential optimization. Maybe I'm missing
something.
I'm also feel like this is over engineering and not sure whether it'll
become a overhead rather than a optimisation. IMO we need to have some
serious discussions in the maling list before doing something like
that..That's the very reason this is avoided in the initial impl.
Most suitable usecase in here will be the intermediaries, which
normally do not read the attachments.. Interesting figure in here will
be the number of usecases where people actually use attchments with
intermediaries..
~Thilina
