Return-Path: Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list axis-dev@xml.apache.org Received: (qmail 47324 invoked from network); 2 Feb 2001 14:17:15 -0000 Received: from gatekeeper-s.gts.cz (HELO smtp.idoox.com) (194.213.203.154) by h31.sny.collab.net with SMTP; 2 Feb 2001 14:17:15 -0000 Received: (qmail 22917 invoked by uid 620); 2 Feb 2001 14:16:49 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 2 Feb 2001 14:16:49 -0000 Date: Fri, 2 Feb 2001 15:16:49 +0100 (CET) From: Jacek Kopecky X-Sender: jacek@bimbo.in.idoox.com To: axis-dev@xml.apache.org Subject: Re: [Vote] 1 Msg or 2 In-Reply-To: <20010201.17063800@kevinm01.xmls.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N As indicated in my pictures, the intermediaries are like targetted services, wrapping the next SOAP application, so there's no need for this copying request to response here. Can you come up with some other use case for being able to do this copying? Jacek Kopecky Idoox On Thu, 1 Feb 2001, Kevin Mitchell wrote: > +1 for two messages presented thru the MessageContext. One message will > likely lead to undo complication in the public API to manage the original > state vs the current state. > > However, I think it should be possible to modify the original message and > send it as the response, without instantiating two distinct message > objects. I imagine this will be especially efficient for intermediaries > that peform specific processing as directed by header entries, remove > those header entries, and pass the message on or fault. In this case a > good portion of the original message may be retained verbatim. Examples > are authentication or routing intermediaries. > > > >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< > > On 2/1/01, 9:37:55 AM, Doug Davis wrote regarding [Vote] 1 > Msg or 2: > > > > To help move things along, I'd like to propose that > > we VOTE on one of the smaller open issues - one message > > or two in the MessageContext. > > I propose that we have two messages, an incoming and > > an outgoing (or an request and a response - we can > > work on the words after the vote). From the e-mails > > I think that's where most (not all) people are but > > I'd like to have a formal vote to try to bring this to > > a close. Committers, if you vote -1 please give a > > details list of reasons why one message would be better > > in an effort to sway us to your side. Likewise, if you > > vote +1 and can think of reasons why one message just > > won't cut it please let us know of those too. > > -Dug >