How do you know you've got attachments?

[Rob Jellinghaus <ro...@unrealities.com>]

(I'm sending these various attachment design issues to the list, partly because I genuinely do want input, and partly because some folks here have in the past requested more visibility into ongoing design topics.)

When sending an outbound message, how should Axis determine whether to use a MIME enclosure or not?

The simple answer is "if there are any attachments, send a MIME envelope.  (Duh!)"

However, one common scenario for using attachments will be that users simply pass a DataHandler as an argument to a Call object.  (Apache SOAP supports this -- just pass a DataHandler as argument, and it will be serialized as an attachment, and deserialized as a DataHandler on the other side.)

So if the user passes a DataHandler as an argument, rather than explicitly calling any addBodyPart-like API, then when does Axis recognize that there are now attachments in the Message?

There are two alternatives:

- When SOAPBodyElements are added to a SOAPEnvelope, they could be checked to see if they contain DataHandlers.
	Pro: this is done before any serialization, so you can know upfront you need to create a MIME envelope.
	Con: this would be complex and there isn't any precedent for it.

- When an envelope is serialized, any DataHandlers encountered could be converted into attachments.
	Pro: this leverages the serialization framework, and lets it do its job.
	Con: you have to serialize the whole envelope before you start sending any MIME content, since it is envelope serialization that tells you what attachments you must send.

Apache SOAP takes the second strategy... actually, even worse:  it serializes, not only the envelope, but also all the attachments!  It buffers them all in memory and then sends the whole buffer.  This means that Apache SOAP's memory overhead is something like 2x the size of the attachments themselves.

I plan to pursue the second strategy:  serialize the envelope (only!) into a buffer before sending.  This means that we will not support streaming out very huge envelopes, but I think that's OK -- we're prioritizing support for huge attachments, not huge envelopes.

Thoughts?  Lack of response will be interpreted as assent :-)
Cheers!
Rob