Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
Subject: RE: Axis C++ 1.2 trasport support
From: Susantha Kumara <susantha@opensource.lk>
Reply-To: susantha@opensource.lk
To: Apache AXIS C Developers List <axis-c-dev@ws.apache.org>
In-Reply-To: <20040423082645.4855.qmail@web40611.mail.yahoo.com>
References: <20040423082645.4855.qmail@web40611.mail.yahoo.com>
Content-Type: text/plain
Organization: LSF
Message-Id: <1082723929.6671.119.camel@susantha>
Mime-Version: 1.0
Date: Fri, 23 Apr 2004 08:38:49 -0400
Content-Transfer-Encoding: 7bit

Hi Samisa,

Why should we decide what parser(s) is(are) used at compile time. Rather
we can let it happen at runtime. The name of the shared object (or DLL)
can be taken from a configuration file.
For exmaple: In your machine you can have 
	libAxisSoapParserExpat.so and
	libAxisSoapParserXerces.so
But Axis uses the parser specified in the axiscpp.conf by say line
	AXISSOAPPARSER=libAxisSoapParserXerces

Or we can hard code the name of the parser in Axis and user have to
rename his library to that name say libAxisSoapParser.so

---
Susantha

On Fri, 2004-04-23 at 04:26, Samisa Abeysinghe wrote:
> We can keep thecompiler directive as it is and need to make sure that
> multiple compiler directives are possibe.
> This is because one can choose to use only Xerces, while another may
> choose to use both Xerces and Expat. Also there can be situations that
> users would wish to include their own parsers.
> (simply speaking one should be able to use -DUSE_EXPAT_PARSER
> -DUSE_XERCES_PARSER together)
> This needs bit of work
>  
> Also there is another work package related to this.
> That is for those who have selected to compile with multiple parsers,
> there needs to be a mechanism to configure what parser to use. Hence
> configuration support need to be built. (it would be nice if we could
> do that for transport as well)
>  
> If the Parser abstraction layer API could be well defined, third party
> parsers could be plugged in by users easily. At the moment the API is
> not very clear.
> (Can we document this?)
>  
> Thanks,
> Samisa...
> 
> Susantha Kumara <susantha@opensource.lk> wrote:
>         Yes we can include this in 1.2 release plan. Both features
>         
>         1. Transport layer abstraction
>         2. SOAP parser abstraction
>         
>         But there is another place that needs parser abstraction. That
>         is wsdd
>         parsing. At the moment a compiler directive decides that too.
>         We have to
>         get rid of that compiler directive too. Am I correct ?
>         
>         ---
>         Susantha
>         
>         On Fri, 2004-04-23 at 01:06, Samisa Abeysinghe wrote:
>         > >even better if we could get to the point where these plugs
>         (like 
>         > >expat/xerces, libwww, etc) would be possible by
>         configuration file 
>         > >rather than recompile.
>         > 
>         > +1
>         > 
>         > This will need a bit of architectural restructuring; but it
>         is worth
>         > the effort.
>         > Can we include this in 1.2 plan please?
>         > 
>         > Thanks, 
>         > Samisa...
>         > 
>         > 
>         > 
>         >
>         ______________________________________________________________________
>         > Do you Yahoo!?
>         > Yahoo! Photos: High-quality 4x6 digital prints for 25
> 
> ______________________________________________________________________
> Do you Yahoo!?
> Yahoo! Photos: High-quality 4x6 digital prints for 25