Basic attachment design questions

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

Two issues have come up on which Rick and I seek feedback:

1) Are attachments by definition part of Message?  i.e. should attachment methods & attachment logic be part of the core org.apache.axis.Message class?

Making them part of Message is in some sense correct (they semantically *are* part of the incoming message), and certainly is expedient for the implementation.  But making the attachment support modular simplifies the base Message class and reduces mandatory dependencies on other packages, such as mail.jar and activation.jar (used for attachment processing).

One proposal for making them modular would be to leave org.apache.axis.Message alone, to create an org.apache.axis.attachments.MessageAttachments interface (for the attachment-related methods added to Message), and then making "org.apache.axis.attachments.MessageWithAttachments extends Message implements MessageAttachments" to actually implement the additional methods.  Then a James-like MessageFactory could hide the MessageWithAttachments logic.

(Note that I prefer org.apache.axis.attachments to org.apache.axis.message.attachments because there are likely to be subpackages someday (mime, dime, etc.), and >5 levels of package nesting is painful.)

2) Assuming that attachments are *not* part of Message, should mail.jar and activation.jar be optional?  Making them optional requires use of dynamic invocation everywhere that the Axis core engine calls into the org.apache.axis.attachments package (which will not be compiled if mail.jar and activation.jar are unavailable).

All feedback appreciated!

Cheers,
Rob

Re: Basic attachment design questions

[Nelson Minar <ne...@monkey.org>]

>1) Are attachments by definition part of Message?

In my experience, most folks doing SOAP right now aren't using SOAP
with attachments. (Grand Central being the exception I already
remarked on). And it's not clear that SOAP-with-attachments will be
the way we do things in six months; DIME looks awfully good, for
example. That would argue for factoring attachment support into a
separate class.

One other force - it'd be great if a SOAP system could not pay the
cost of parsing attachments unless it actually wants to read the
attachments. I could imagine this being useful for a SOAP router, for
instance. That would require lazy parsing - is that possible to do?

>One proposal for making them modular would be to leave
>org.apache.axis.Message alone, to create an
>org.apache.axis.attachments.MessageAttachments interface (for the
>attachment-related methods added to Message), and then making
>"org.apache.axis.attachments.MessageWithAttachments extends Message
>implements MessageAttachments"

I like the idea of that. But does that kind of factoring suggest that
Message itself should be an interface, not a concrete class?

>2) Assuming that attachments are *not* part of Message, should
>mail.jar and activation.jar be optional?

If their licenses allow distribution with Axis itself, I don't see any
great need to make them optional at compile time. I'd much rather have
proper type checking on the code. At runtime, I'd expect them to be
optional until needed.

mailapi.jar is 149k, activation.jar is 44k. Both are under the Sun
binary license, but I think they include a supplemental license giving
permission to distribute.

                                                     nelson@monkey.org
.       .      .     .    .   .  . . http://www.media.mit.edu/~nelson/