Return-Path: Delivered-To: apmail-xml-axis-dev-archive@xml.apache.org Received: (qmail 41226 invoked by uid 500); 29 Oct 2001 12:31:12 -0000 Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@xml.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-dev@xml.apache.org Received: (qmail 41211 invoked from network); 29 Oct 2001 12:31:11 -0000 Message-ID: <00c301c16075$92092ec0$6b00a8c0@ne.mediaone.net> From: "Glen Daniels" To: References: <3.0.1.32.20011028105653.0147a6d8@unrealities.com> <3.0.1.32.20011028213855.0123eab8@unrealities.com> Subject: Re: How do you know you've got attachments? Date: Mon, 29 Oct 2001 07:31:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Hi Rob: > Yes, but again, if we buffer the root part first, then we can let the >presence or absence of DataHandlers tell us what to do. Heck, maybe we want >both... and remember, what about the server side, where a service may just >return a Java object without ever directly accessing the Message itself??? >(You (and Doug) seem not to consider that case when discussing this issue in >this thread.) The point I was trying to make is that it's always better to know up front if attachments will be necessary, and that we can pretty easily make it so you always do know up front. My initial reaction to your server side point is that if you might want to send attachments in returned object, you should either a) use a service method with a MessageContext argument, or b) deploy your service with an "enableAttachments=true" option. I'd rather not have to buffer the entire envelope in cases where we don't need to, and so IMHO you should have to do something (either explicit API calls or setting deployment info) to get the engine to behave that way. > >> The first code I check in will probably support attachments on the > >message, > >>but will not support automatically resolved href's in the message itself. > >>That'll come later. > > > >In other words you'll support writing attachments, but not deserializing the > >hrefs which refer to them as DataHandlers? > > Yes, but only as an interim checkin... it certainly won't be complete (or >shippable for Axis 1.0) until the serialization is working. If you get the framework and the first part checked in, I betcha someone else might be willing to whip off the deserialization part. --Glen