axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samisa Abeysinghe <samisa_abeysin...@yahoo.com>
Subject Re: Axis C++ 1.2 trasport support
Date Mon, 26 Apr 2004 03:54:52 GMT
Susantha,
    What I meant by a 'configuration mechanism' is to use a conf file.

    Currently the compiler directives are used from within the parser abstraction layer code.
    This is more like hardcoding the parser.
    This means the parser abstraction layer has to be improved.

    Infat I made a mistake. I used the compiler directives to make a configuration selection.
Actually what has to be done is to specify a configaration parameter.
    Once there is flexibility to select the parser from a conf file, to select the parser,
there
need to be multiple parser support compiled.
    At the moment this kind of selection is done by modifying the Makefile.am file. But if
you use
configuration parameters in the way that I have suggested then the users would not have to
edit
the Makefile.am in the parser folder. Rather they could use the directive during config time
and
select  what parsers they are going to use at run time.
    

> >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
    I do not think this is a good idea because then the user has to rebuild the source to
et
another parser support.
    Rather dynamic switching would be ideal.

Thanks,
Samisa...

--- Paul Fremantle <pzf@hursley.ibm.com> wrote:
> Susantha
> 
> That sounds cool.
> 
> Paul
> 
> Susantha Kumara wrote:
> 
> >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
> >

> >
> >---
> >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
> >>    
> >>
> >
> >
> >  
> >
> 



	
		
__________________________________
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25
http://photos.yahoo.com/ph/print_splash

Mime
View raw message