[Axis Proto] Message Reader/Writer Prototup Update

[James Snell <jm...@intesolv.com>]

All,

Just a quick update,

Time is precious... the Reader/Writer prototype will be coming very soon
(next day or so), please be patient with me.  Once the basic prototype is
up, we can all slam it around and see what comes of it.

- James

> -----Original Message-----
> From: Doug Davis [mailto:dug@us.ibm.com]
> Sent: Tuesday, January 23, 2001 4:06 AM
> To: soap-dev@xml.apache.org
> Subject: Re: [Axis Proto] Codebase #6
> 
> 
> Actually, I was thinking something more along the lines of
>   msg.getAs( <thetype> );
> so it would be pluggable.
> Whether the converter is called from the handlers or called
> from the message (or messageContext) isn't really a big deal
> to me - it all seems like about the same thing.  I just don't want
> handler writers to have to do more work than needed so I thought
> pushing it into the Message or MessageContext would be better,
> but either way is fine.
> -Dug
> 
> 
> Jacek Kopecky <ja...@idoox.com> on 01/22/2001 10:03:12 AM
> 
> Please respond to soap-dev@xml.apache.org
> 
> To:   soap-dev@xml.apache.org
> cc:
> Subject:  Re: [Axis Proto] Codebase #6
> 
> 
> 
>  Hello Dug. 8-)
>  I don't think this would do, because you would have a fixed set of
> getAsX methods, that's not really extensible. This also suggests the
> reader/writer approach.
>  I suggest that we pursue the original path of handlers doing
> canonicalization/serialization. There this using whatever we need
> would become a config issue:
>  If handler A uses stream, handler B uses DOM and handler C uses
> SOAPEnvelope, and we want A->B->C, we could do A->X1->B->X2->C, where
> X1 is a convertor from stream to (P)DOM which is inserted in a well
> known place in the context (like "Message.DOM"), X2 inserts a
> SOAPEnvelope wrapper for the DOM into "Message.SOAPEnvelope".
>  The stream would originally be accessible from "Message.stream", the
> first handler (A) or the first transformer (X1) would have to remove
> that (unless the stream stays untouched) or replace that (if A e.g.
> decrypts the stream into another stream).
>  The namespace in the context under "Message.*" is easily extensible
> and the admin (or the WSDD creator) should know that a handler will
> want the message in a particular form.
>  If we use PDOM and if the SOAPEnvelope implementation is lazy as well
> we can easily accomplish the Readers' effect of lazy parsing.
> 
>  As part of the AXIS package there would be a set of converters
> between different "Message.*" formats.
> 
>  What was the point for Readers/writers?
>  Maybe less work for the admin, but I think that in order for
> readers/writers to be as extensible they would have to be plugin-based
> and configurable as well, and we already have a way to insert a plugin
> - make it a handler. Right? 8-)
>  Regards,
> 
>                             Jacek Kopecky
>                                Idoox
> 
> 
> 
> On Mon, 22 Jan 2001, Doug Davis wrote:
> 
>  > I always thought that we should be able to just say:
>  >   message.setContent( whatever) ;
>  > and the message would  be able to support a list
>  > of different types, stream, bytes, string, XML, SOAPEnv, XPEnv...
>  > The code could then just call:
>  >   message.getAsSOAPEnv();
>  > or
>  >   mesage.getAsXPEnv();
>  > and the message object would do the converting for us.
>  > It seems like if we had a pluggable system where different
>  > converters could be plugged in we could handle any type
>  > of data.
>  > -Dug
>  >
>  >
>  > Ryo Neyama <ne...@trl.ibm.co.jp> on 01/22/2001 12:42:59 AM
>  >
>  > Please respond to soap-dev@xml.apache.org
>  >
>  > To:   soap-dev@xml.apache.org
>  > cc:
>  > Subject:  Re: [Axis Proto] Codebase #6
>  >
>  >
>  >
>  > Any comments on this?
>  > We cannot go ahead in prototyping unless we solve this problem.
>  >
>  > Regards,
>  >     Ryo Neyama @ IBM Research, Tokyo Research Laboratory
>  >     Internet Technology
>  >     neyama@trl.ibm.co.jp
>  >
>  > From: Ryo Neyama <ne...@trl.ibm.co.jp>
>  > Subject: Re: [Axis Proto] Codebase #6
>  > Date: Fri, 19 Jan 2001 17:37:41 +0900
>  >
>  > > From: "Yuhichi Nakamura" <NA...@jp.ibm.com>
>  > > Subject: [Axis Proto] Codebase #6
>  > > Date: Fri, 19 Jan 2001 12:01:02 +0900
>  > >
>  > > > I have prepared a new codebase in the following:
>  > >
>  > > > The main change is a generalized Envelope API.  
> Original one was
>  > > > specialized
>  > > > for SOAP, but the current one uses more general names 
> as follows:
>  > > >     SOAPEnvelope -> Envelope
>  > > >     SOAPBodyEntry -> BodyEntry
>  > > >     and so on.
>  > >
>  > > I think this generalizatoin for Envelope API should be too much.
>  > > Because when we implement SOAPEnvelope that has the generalized
>  > > interface 'Envelope', we would write the code as follows:
>  > >
>  > > public class SOAPEnvelope implements Envelope {
>  > >     public void setBody(Body body) {
>  > >        // Sets the body here
>  > >     }
>  > > }
>  > >
>  > > However generalized Body handed as a parameter might not 
> be a SOAPBody
>  > > but an XPBody.  This implies that we have to check the parameter
>  > >  before setting it like this:
>  > >
>  > > public class SOAPEnvelope implements Envelope {
>  > >     public void setBody(Body body) {
>  > >        if (body instanceof SOAPBody) {
>  > >            // Sets the body here
>  > >        } else
>  > >            throw new EnvelopeStructureException("Body must be
>  > SOAPBody!!!");
>  > >     }
>  > > }
>  > >
>  > > It's very ugly to me.  How do you guys think about this?
>  > >
>  > > We don't know how XP will be because there is no draft 
> specification
>  > > yet.  I'm doubting about the reusability of Axis for XP. 
>  Of course,
>  > > some components in Axis should be reused for XP.  
> However, I think the
>  > > core of the XP engine should be designed from scratch anyway.
>  >
>  >
> 
> 
> 
>