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 21572 invoked from network); 2 Feb 2001 02:42:16 -0000 Received: from georgia.yamato.ibm.com (203.141.89.181) by h31.sny.collab.net with SMTP; 2 Feb 2001 02:42:16 -0000 Received: from e022f2n10.jp.ibm.com (d22relay02.yamato.ibm.com [9.68.14.53]) by georgia.yamato.ibm.com (8.11.1/3.7W/NG3.6) with ESMTP id f122fvq72160 for ; Fri, 2 Feb 2001 11:41:57 +0900 Received: from e022f2n7 (d22hubm7 [9.68.14.51]) by e022f2n10.jp.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id LAA81186 for ; Fri, 2 Feb 2001 11:41:57 +0900 Importance: Normal Subject: Re: [Vote] 1 Msg or 2 To: axis-dev@xml.apache.org From: "Yuhichi Nakamura" Date: Fri, 2 Feb 2001 11:41:53 +0900 Message-ID: X-MIMETrack: Serialize by Router on D22HUBM7/22/H/IBM(Release 5.0.3 (Intl)|21 March 2000) at 2001/02/02 11:41:57 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N -1 I still not sure whether the single API is adequate because this excludes other patterns such as public/subscribe. However, at this moment, let me accept the single API. I think the concept of the single API is that we do not distinguish "forwarder" and "pivot" handlers at the API level although each handler has to know which he/she is (I hope that forwader/pivot are proper terms). This point was clearly mentioned by Jacek, and I suppose this hypothesis. If we do not distinguish handlers, why do we need to distinguish request/response messages in MessageContext. A message is just updated by the handler. I guess there is some contradiction here. In terms of the different API, request/response are distinguished. Another practical issue is how to get messages from MessageContext. Dug's MessageContext has getIncomingMessage, etc. My's MessageContext has getMessage. Many forwarder handlers prefer the latter such Digital Signature Handler, Logging handler, etc. If MessageContext has two messages and provides getMessage(), we need a switch (request/reseponse switch :-). A reference implementation of MessageContext is found in TRL proposal directory in axis-cvs. The implementation is extremly simple. Regards, Yuhichi Nakamura IBM Tokyo Research Laboratory Tel: +81-46-215-4668 Fax: +81-46-215-7413 From: "Doug Davis" on 2001/02/01 23:37 Please respond to axis-dev@xml.apache.org To: axis-dev@xml.apache.org cc: Subject: [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