axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sanjiva Weerawarana" <sanj...@opensource.lk>
Subject Re: The OpenSSL DLL and SecureChannel parts of Axis2Transpor
Date Wed, 22 Dec 2004 05:43:59 GMT
ARGHHHHHHHHH!

I can't tell who wrote what in this email .. could folks please
please the remove the unneeded parts of old mail in their reply?
Also please try to quote (with ">" or something like that) or
demarcate the old mail clearly when replying.

My apologies for sounding paternistic but its very hard to follow
a thread otherwise.

Thanks,

Sanjiva.

----- Original Message ----- 
From: "Damitha Kumarage" <damitha@opensource.lk>
To: <axis-c-dev@ws.apache.org>
Sent: Tuesday, December 21, 2004 11:00 AM
Subject: Re: The OpenSSL DLL and SecureChannel parts of Axis2Transpor


> Susantha,
>
> Samisa Abeysinghe wrote:
> The fact that Expat, and LibWWW are in graveyard is not because that
> > Abstraction layers are bad designs or over designs, rather because
> > maintanance is problamatic because of lack of resources. However,
> > keeping them in place keeps the windows open for much needed
> > flexibility.
> >
> > I remember couple or more users asking over the mailing list, if they
> > could use their own transport lib with the core Axis C++ engine. This
> > means that users do want to use their own transport. Hence I do not
> > agree binding HTTP into client engine - IMHO, the way it is now is the
> > best.
> >
> > LibWWW is not thread safe, however, if one wants a feature rich
> > transport, I still suggest that one uses LibWWW based transport. Also,
> > there are thread safe alternatives such as libCurl - which could be
> > integrated using the transport abstraction option available.
> >
> > I do not see any advantage of removing the abstraction layer at all -
> > I see many advantages keeping it in place.
> >
> > Thanks,
> > Samisa...
> >
> >
> >
> > On Mon, 20 Dec 2004 17:30:48 +0600, Damitha Kumarage
> > <damitha@opensource.lk> wrote:
>
> > Hi Samisa,
> > > On Mon, 2004-12-20 at 15:28, Susantha Kumara wrote:
> > > Samisa Abeysinghe wrote:
> > >
> > > Damitha,
> > > >
> > > >     Regarding dynamically loading only the channel:
> > > > >
> > > > >
> > > > > One other thing. Currently  we support dynamically loadble
transport
> support.
> > > > >
> > > > > That means that one can write his own tranport
> > > > > > implementing SOAPTransport.hpp and plug it into axis c++. I
think this
> > > > > >
> > > > > >
> > > should
> > >
> > > be changed. Axis2Transport transport implementation should statically
> > > > > >
> > > > > >
> > > bind to
> > >
> > > axis client engine and it should be the channel that should be
dynamically
> > > > > > loaded. One can write his channel library implementing
Channel.hpp I
> > > > > >
> > > > > >
> > > proposed
> > >
> > > above and plug it into axis c++.
> > > > > > What do you think?.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > I think, it is not only the channel, but the whole of
Axis2Transport
> > > > > should be loaded dynamically. It is tue that the Channel class
handles
> > > > > the socket connection stuff. However, one could choose to
implement,
> > > > > use another HTTP handling lib. The best example I can think of is
> > > > > LibWWW - if that is to be used, no need of current Axis2Transport
> > > > > class.
> > > > >
> > > > >
>
> > > Yes I know that using the api one can implement/use different HTTP
handling
> > > capablities. What I need to point out is whether axis need to provide
this
> > > much flexiblity. Because this kind of unncessary flexiblity we have
wasted lot
> > > of our developer time. To me this should have been an initial design
> > > decision.We wanted support to libwww support and it is now in the
graveyard.
> > > Expat is now resting in graveyard.
> > > I think we should decide where we should provide pluggablity. We can
make
> > > HTTP handling as robust as possible whith our new transport. So
selecting Axis
> > > C++ client means one select our http handling
> > > capblities as well. But we should let him select his own channel for
security
> > > reasons etc.
> > >
> > > So still I have the feeling that transport is part of client engine
and it is
> > > the channel we should make a dll. I am not proposing this change to
our
> > > existing architecture. I'm just interested to know  what you think.
> > >
> > >
> > > Samisa...
> > > > >
> > > > >
> > > > > On Fri, 17 Dec 2004 11:47:19 +0600, Damitha Kumarage
> > > > > <damitha@opensource.lk> wrote:
> > > > >
> > > > > Hi Fred, Samisa,
> > > > >
> > > > > Although this is too late I think the cleanest solution should be
> something
> > > > > > like this
> > > > > >
> > > > > > We have a base class called Channel.hpp which has pure virtual
methods
> > > > > > It have all the methods exepected from a tcp channel, secure
or
> unsecure.
> > > > > >
> Now any body can write his own secure or unseucure channel implementing
this
> > > > > > interface. .
> > > > > >
> > > > > > One can write a channel dll implementing this Channel.hpp
interface.
> > > > > > This dll can be for a seucure channelling or unsecure
channelling.
> > > > > >
> > > > > > For default unsecure channeling we derive TCPChannel.hpp from
> > > > > >
> > > > > >
> > > Channel.hpp for
> > >
> > > unsecure channelling(statically). The unused secure methods can have
dummy
> > > > > > implementations.
> > > > > >
> > > > > > For default secure channeling we can write a dll which uses
OpenSSL and
> > > > > >
> > > > > >
> > > secure
> > >
> > > channel class derive from Channel.hpp interface.
> > > > > >
> > > > > > This way it is very clear and I'm sure that I can make this
work
both on
> > > > > > windows and linux because I have tested this functionlity on
both
> platforms.
> > > > > >
> > > > > > Maybe we can do this for 1.5 because it is now too late for
1.4.
The
> reason
> > > > > > that I could not come up with this is that I tried to keep now
existing
> > > > > > Channel.hpp and SecureChannel.hpp unchanged.
> > > > > >
> > > > > > However note that in this way it is not possible to reuse the
tcp
> > > > > >
> channel open
> > >
> > > functionality from Channel.cpp for secure channel, like we earlier
wanted,
> > > > > > because now Channel.hpp has all pure virtual functions.
> > > > > > and it is neccessary for loading a dll in a seperate space(I
guess)
> > > > > >
> > > > > > One other thing. Currently  we support dynamically loadble
transport
> > > > > >
> > > > > >
> > > support.
> > >
> > > That means that one can write his own tranport
> > > > > > implementing SOAPTransport.hpp and plug it into axis c++. I
think this
> > > > > >
> > > > > >
> > > should
> > >
> > > be changed. Axis2Transport transport implementation should statically
> > > > > >
> > > > > >
> > > bind to
> > >
> > > axis client engine and it should be the channel that should be
dynamically
> > > > > > loaded. One can write his channel library implementing
Channel.hpp I
> > > > > >
> > > > > >
> > > proposed
> > >
> > > above and plug it into axis c++.
> > > > > > What do you think?.
> > > > > >
> > > > > > thanks
> > > > > > damitha
> > > > > > --
> > > > > > Damitha Kumarage
> > > > > > hSenid Software International (PVT) Ltd
> > > > > > damitha@hSenid.lk
> > > > > >
> > > > > > Lanka Software Foundation (http://www.opensource.lk)
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > Yes the transport can be of some other protocol than HTTP. So this
> > > > >
> > > > >
> > > AxisTransport API should be protocol independent.
> > >
> > > Providing support for other transports is also our responsiblity. But
this
> > > need not necessary make our whole transport a dll. This is just a
thought.
> > > Please give more thoughts
> > >
> > > thanks
> > > damitha
> > >
> > > --
> > > Damitha Kumarage
> > > hSenid Software International (PVT) Ltd
> > > damitha@hSenid.lk
> > >
> > > Lanka Software Foundation (http://www.opensource.lk)
> > >
> > >
> > >
> > >
> >
> >
> > I agree with Samisa to keep these abstraction layers in place. Also this
> abstraction layers help anyone to develop his/her own transports and/or
> parsers without much knowladge on the rest of Axis. For example one can
write
> a transport that compresses the packet before sending and decompresses the
> packet after it reads from socket or what ever.
>
> I think one can write a loadalble channel that compress the packet before
> sending and decompresses the packet after it reads
>
> thanks
> damitha
>
> Regards,
>
> Susantha.
>
>
>
>
> --
> Damitha Kumarage
> hSenid Software International (PVT) Ltd
> damitha@hSenid.lk
>
> Lanka Software Foundation (http://www.opensource.lk)
>
>


Mime
View raw message