axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Rineholt" <rineh...@us.ibm.com>
Subject Re: RE: Axis and attachments (non-RPC)
Date Thu, 31 Jan 2002 15:21:47 GMT
>> >I was looking at the Axis for non-RPC messaging, and noticed
>> that there
>> >isn't much there. (not even in TODO comments that I saw).
>> >What is the planned future?
>> >1) No clean way to set Content-Id of attachments.
>> >You have to extract all of the attachments from the
>> Attachments class,
>> >change headers manually, then re add them to the Attachments.
>> >1b) If you update Content-Id of the Attachment, it will not be saved
>> unless
>> >you re-add it to attachments.
>> 1a+ b)  Content-Id is generated for you.  There should be no
>> significance
>> given to the
>> content-id value itself.  Can you please give a usage
>> scenario where this
>> would be necessary?
>If you use RPC you don't care much for a content-id. However, as soon as
you
>step away from RPC into messaging, you will need some way for a service to
>know what attachments to look for. You *could* put in the name of the
>attachment into SOAP header/body you send, but it is much more processing
on
>the client side. Naming your attachment is much simpler.
>Use case: Intermediary that does XSLT transformations. A soap header tells
>it to pick up original xml from "cid:original.xml" and xslt instructions
>from "cid:instructions.xsl". It is useful for automation purposes to have
>that header prebuilt, and just rename the attachments.
Content-id should be "universally" unique per attachment .  From what I'm
 understanding of your requirements using "content-location" header would
be
 far more appropriate.  I would also suggest  using a value that includes a
 URL plus a uuid type string. .  We don't set or modify the
content-location header.
Second if you are creating a specification, I would strongly suggest that
you not
use either of these as the means of identifying your attachments.  In my
opinion,
using an element in your XML document with an href attribute to the
attachment is
in most cases I  can think of a better approach.  In the approach you are
using, you
are binding your specification to the wire protocol (mail-attachments).
There are emerging protocols
such as DIME http://www.ietf.org/internet-drafts/draft-nielsen-dime-00.txt
that are really
more appropriate.  By using an href and allowing the SOAP processor to
resolve the
attachment your specification only is dependant on the XML.  Yes, you do
have to do
some extra processing, but I would assume that the XML would be processed
eventually?
Having an element associated with the attachment I think is also from a
design point
preferable.  Also, there really should be no significance given to the
value of content-id and
it would not be unreasonable for an intermediary to take an in coming
SOAP/MIME message
and send it out as a SOAP/DIME replacing content-ids with DIME payload
identifiers.
The value of XML is that it is a recognized protocol for exchanging data,
any thing you
can do to limit your specification to just that, IMO is an important design
consideration.
>> >1c) *BUG* Mime allows for duplicate headers, but they get
>> eaten by HashMap
>> >here.
>> Ok. But may I ask what you are doing with headers from a
>> SOAP/ Web Service
>> type
>> application that depends on this?  Mind you I'm not saying
>> that this is
>> correct but I'm wondering
>> what the usage pattern is that would use this so I can assess
>> how high of a
>> priority it would be to fix.
>There is no high priority in it yet, it more of a compatibility issue.
>SOAP is not protocol dependent. For instance SMTP allows for multiple To:
>headers. There is nothing stopping a person from using his/her SMTP server
>to broadcast SOAP messages... if Axis doesn't eat duplicate headers :)
>> >2) There is no way to add an attachment to the list if you
>> already have
>> one.
>> >From another message lets say.
>> >Example:
>> >Attachments atts=msg.getAttachments();
>> >DataHandler dh=new DataHandler(new
>> >FileDataSource("data.dat"));
>> >AttachmentPart
>> >part=(AttachmentPart)atts.createAttachmentPart(dh);
>> >part.addMimeHeader(HTTPConstants.HEADER_CONTENT_ID ,
>> >"myAttachmentId");
>> >ArrayList parts=new ArrayList(2);
>> >parts.add(part);
>> >atts.setAttachmentParts(parts);
>> >2b) Needs add(AttachmentPart), getAttachmentByContentId(),
>> getIterator() -
>> >Would be nice if remove() and add() would function on iterator.
>> Let me consider the impact of this some more.
>Again this is not an issue related to RPC but is rather important for xml
>messaging(non-RPC), and intermediaries.
>> >3) Reading contents of the AttachementPart is awkward.
>> >getActiviationDataHandler() method is not public, but is on
>> package level.
>> >Is it a typo or as intended?
>> >AttachmentUtils has     public static DataHandler
>> >getActiviationDataHandler(Part part)   method, but its kind
>> of odd way of
>> >doing it.
>> As one of the requirements the core of Axis can be compiled without
>> attachment
>> support.  This is one of reasons for some of the "round
>> about" manner of
>> things.
>Well... If a client is already using an AttachmentPart class, we can
assume
>that he does have attachment support, can we not?
No, attachment support can be COMPILED in and or left out.
>> >4) There is nice BoundaryDelimitedStream to read the
>> attachments, but you
>> >still rely on scary javax.mail code to create outgoing
>> messages. Are there
>> >any plans to change that?
>> No.  This code has been used and tested.
>> >P.S. What is the preferred way of sending patches, since
>> only committers
>> >have write access to cvs?
>> http://xml.apache.org/source.html.
>> >-Taras
>>
>>
>> Rick Rineholt
>> "The truth is out there...  All you need is a better search engine!"
>>
>> rineholt@us.ibm.com
>>


Rick Rineholt
"The truth is out there...  All you need is a better search engine!"

rineholt@us.ibm.com


Mime
View raw message