You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-dev@ws.apache.org by Pavel Ausianik <Pa...@epam.com> on 2002/11/11 17:34:26 UTC
SOAPTransport.receive()
Hello,
I have found that we have interface SOAPTransport with method public
BufferedReader receive ();
All three known implementations of SOAPTransport use following code for this
String s = .... // Create a Envelope String
BufferedReader reader = new BufferedReader(new StringReader())
....
in = st.receive();
payloadStr = IOUtils.getStringFromReader(in);
So we get a good transformation from String to String using at least two
Readers, and big enough buffers. The code is used on each Call
I think It worth to change interface and all usage to public String receive
().
What do you think?
Pavel
Re: SOAPTransport.receive()
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
Pavel, another possible improvement: apparently its not needed to
generate content length on responses since we don't do HTTP/1.1
anyway. Dropping that would take away an extra write layer ..
(I believe Axis has moved away from content-length already.)
Sanjiva.
----- Original Message -----
From: "Scott Nichol" <sn...@scottnichol.com>
To: <so...@xml.apache.org>
Sent: Monday, November 11, 2002 12:07 PM
Subject: Re: SOAPTransport.receive()
> I would like to see an analysis of the whole code path for reading the
> response to see all the redundancies in processing. I think that when
> MIME attachment handling was added, there was an opportunity to remove
> or restructure code that was not seized.
>
> At the same time, I am worried about changing existing interfaces that
> would break people's code.
>
> Scott Nichol
>
> ----- Original Message -----
> From: "Pavel Ausianik" <Pa...@epam.com>
> To: <so...@xml.apache.org>
> Sent: Monday, November 11, 2002 11:34 AM
> Subject: SOAPTransport.receive()
>
>
> > Hello,
> >
> > I have found that we have interface SOAPTransport with method public
> > BufferedReader receive ();
> >
> > All three known implementations of SOAPTransport use following code
> for this
> >
> > String s = .... // Create a Envelope String
> > BufferedReader reader = new BufferedReader(new StringReader())
> >
> >
> > ....
> >
> > in = st.receive();
> > payloadStr = IOUtils.getStringFromReader(in);
> >
> >
> > So we get a good transformation from String to String using at least
> two
> > Readers, and big enough buffers. The code is used on each Call
> > I think It worth to change interface and all usage to public String
> receive
> > ().
> >
> > What do you think?
> >
> > Pavel
> >
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@xml.apache.org>
> > For additional commands, e-mail: <ma...@xml.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: SOAPTransport.receive()
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
Pavel, another possible improvement: apparently its not needed to
generate content length on responses since we don't do HTTP/1.1
anyway. Dropping that would take away an extra write layer ..
(I believe Axis has moved away from content-length already.)
Sanjiva.
----- Original Message -----
From: "Scott Nichol" <sn...@scottnichol.com>
To: <so...@xml.apache.org>
Sent: Monday, November 11, 2002 12:07 PM
Subject: Re: SOAPTransport.receive()
> I would like to see an analysis of the whole code path for reading the
> response to see all the redundancies in processing. I think that when
> MIME attachment handling was added, there was an opportunity to remove
> or restructure code that was not seized.
>
> At the same time, I am worried about changing existing interfaces that
> would break people's code.
>
> Scott Nichol
>
> ----- Original Message -----
> From: "Pavel Ausianik" <Pa...@epam.com>
> To: <so...@xml.apache.org>
> Sent: Monday, November 11, 2002 11:34 AM
> Subject: SOAPTransport.receive()
>
>
> > Hello,
> >
> > I have found that we have interface SOAPTransport with method public
> > BufferedReader receive ();
> >
> > All three known implementations of SOAPTransport use following code
> for this
> >
> > String s = .... // Create a Envelope String
> > BufferedReader reader = new BufferedReader(new StringReader())
> >
> >
> > ....
> >
> > in = st.receive();
> > payloadStr = IOUtils.getStringFromReader(in);
> >
> >
> > So we get a good transformation from String to String using at least
> two
> > Readers, and big enough buffers. The code is used on each Call
> > I think It worth to change interface and all usage to public String
> receive
> > ().
> >
> > What do you think?
> >
> > Pavel
> >
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@xml.apache.org>
> > For additional commands, e-mail: <ma...@xml.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
Re: SOAPTransport.receive()
Posted by Scott Nichol <sn...@scottnichol.com>.
I would like to see an analysis of the whole code path for reading the
response to see all the redundancies in processing. I think that when
MIME attachment handling was added, there was an opportunity to remove
or restructure code that was not seized.
At the same time, I am worried about changing existing interfaces that
would break people's code.
Scott Nichol
----- Original Message -----
From: "Pavel Ausianik" <Pa...@epam.com>
To: <so...@xml.apache.org>
Sent: Monday, November 11, 2002 11:34 AM
Subject: SOAPTransport.receive()
> Hello,
>
> I have found that we have interface SOAPTransport with method public
> BufferedReader receive ();
>
> All three known implementations of SOAPTransport use following code
for this
>
> String s = .... // Create a Envelope String
> BufferedReader reader = new BufferedReader(new StringReader())
>
>
> ....
>
> in = st.receive();
> payloadStr = IOUtils.getStringFromReader(in);
>
>
> So we get a good transformation from String to String using at least
two
> Readers, and big enough buffers. The code is used on each Call
> I think It worth to change interface and all usage to public String
receive
> ().
>
> What do you think?
>
> Pavel
>
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>
Re: SOAPTransport.receive()
Posted by Scott Nichol <sn...@scottnichol.com>.
I would like to see an analysis of the whole code path for reading the
response to see all the redundancies in processing. I think that when
MIME attachment handling was added, there was an opportunity to remove
or restructure code that was not seized.
At the same time, I am worried about changing existing interfaces that
would break people's code.
Scott Nichol
----- Original Message -----
From: "Pavel Ausianik" <Pa...@epam.com>
To: <so...@xml.apache.org>
Sent: Monday, November 11, 2002 11:34 AM
Subject: SOAPTransport.receive()
> Hello,
>
> I have found that we have interface SOAPTransport with method public
> BufferedReader receive ();
>
> All three known implementations of SOAPTransport use following code
for this
>
> String s = .... // Create a Envelope String
> BufferedReader reader = new BufferedReader(new StringReader())
>
>
> ....
>
> in = st.receive();
> payloadStr = IOUtils.getStringFromReader(in);
>
>
> So we get a good transformation from String to String using at least
two
> Readers, and big enough buffers. The code is used on each Call
> I think It worth to change interface and all usage to public String
receive
> ().
>
> What do you think?
>
> Pavel
>
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>