axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Hawkins <HAWKI...@uk.ibm.com>
Subject Re: Fw: Platform specific class
Date Thu, 13 Jan 2005 10:15:58 GMT
So, I think we can conclude that we would like to use APR and that we 
would like a more OO model on the classes that we have and that they are 
still required.
However, we do not intend to do this until post 1.5

Agreed?

John Hawkins



Samisa Abeysinghe <samisa.abeysinghe@gmail.com> wrote on 13/01/2005 
02:18:26:

> > Platform specific class will only ever be called from C++ 
> interally and never by external C applications
> 
> +1.
> 
> Samisa...
> 
> 
> On Wed, 12 Jan 2005 09:59:11 +0000, Mark Whitlock
> <mark_whitlock@uk.ibm.com> wrote:
> > 
> > 
> > Hi,
> > The generated C stubs can be compiled with a C compiler and will not 
need a
> > C++ compiler. The C support is being separated out from the Axis C++ 
engine
> > into a separate DLL/shared library. So C applications will link with
> > AxisClientC.dll.
> > 
> > Currently the PlatformAutoSense.hpp and other platform header files 
are not
> > externalised (they are in src not include) so C/C++ generated stubs 
cannot
> > use them. Any platform support is in GDefine.hpp or AxisUserAPI.hpp. 
I'm
> > not proposing to change this so the Platform specific class will only 
ever
> > be called from C++ interally and never by external C applications.
> > Mark
> > Mark Whitlock
> > IBM
> > 
> > ----- Forwarded by Mark Whitlock/UK/IBM on 12/01/2005 09:43 -----
> > 
> >              Nadir Amra
> >              <amra@us.ibm.com>
> >  To 
> >              12/01/2005 06:58          "Apache AXIS C Developers List"
> >                                        <axis-c-dev@ws.apache.org>
> >  cc
> >              Please respond to
> >               "Apache AXIS C Subject 
> >              Developers List"          RE: Platform specific class
> > 
> > 
> > I guess I would like to tackle the question of whether the "generated 
C
> > stubs can be compiled by just using a C compiler?".
> > 
> > I guess the person working on C stub generation needs to answer that.
> > However, even if customer requires a C++ compiler, generating C stubs 
is
> > still useful.  Yes, the customer would have to compile C++ code, but 
does
> > not have to understand what the C++ code is doing, as long as customer 
has
> > the ability to call a C stub to access a Web Service.  That is the 
most
> > important thing.
> > 
> > Obviously, I would prefer a purely C implementation for C stub 
generation,
> > which means Axis would have to provide a C interface to the Axis 
engine
> > that is compiled with C++ compiler (the C interface would be 
wrapper'ed
> > with extern "C").  The C interface then can access the C++ engine.  I
> > thought that was the direction we were going on this, but I may be
> > mistaken.
> > 
> > Even in a purely C stub interface, I think we can go with C++ 
abstraction
> > as long as we provide C interfaces to the platform abstractions.  That 
is
> > a possible solution.  Discussion on how the abstraction should be
> > implemented should be left for later....unless you want to discuss 
now. We
> > can start a new thread on that.
> > 
> > "Lilantha Darshana" <ldarshana@edocs.com> wrote on 01/10/2005 06:03:55 
PM:
> > 
> > >
> > > Let me make myself clear on what I said.
> > > We can have the suggested bridge pattern to make axis transparent
> > > from platform
> > > specific functions. i.e decouple an abstraction from its real
> > implementation.
> > > This would make things more manageable esp. when OS/HW or
> > > environment (runtime lib etc)
> > > changes. Better option is to have layered architecture (PAL) and
> > > grow up from it.
> > > This is not a short term answer, but is a long term solution.
> > >
> > > One question will crops up when we convert platform support to
> > > classes as pointed by
> > > Nadir is: when we create C stubs if C stubs need these functions
> > > what shall we do?
> > > My question is, can the generated C stubs be compiled by just using
> > > a C compiler (none C++)
> > > and link it with axis libs? If not, my general assumption is:
> > > creating C stubs does not
> > > make much sense to me, if you do not have strong arguments of
> > > supporting C stubs.
> > > May be I have not heard of your perspectives on that(we can discuss)
> > > We can create C++ stubs and call any external APIs from it - this
> > > external API could
> > > have been written by any language not just C. Often, with
> > > webservices we would rather
> > > require to call/access to external code written in different legacy
> > > languages, eg. COBOL.
> > > So, how you would suggest to call a service written in any other
> > > language than C?
> > > Therefore, my understanding is, if we additionally support C 
services
> > that
> > > does not solve all requirements what ppl try to resolve by using
> > > webservices these days.
> > >
> > > APR is just one of the good option if we need some OS/HW dependent
> > > functions and make
> > > it transparent to axis when we impl. above design. So APR can be
> > > used to impl. some
> > > of the common functions in the base class. However, this is not
> > > mandatory to go in to
> > > any particular axis release, rather, is a thought whether we have
> > > any complications
> > > on using it. I'm afraid whether I could make much comment about APR
> > > running on OS/400.
> > > You IBM forks must know about it more than I do. Although, I have
> > > seen that IBM provides
> > > APR with HTTP server for IBM iSeries server. So my assumption is at
> > least 90%
> > > is compatible.
> > >
> > > Functions like:
> > > #define PLATFORM_STRTOASC( x ) ( x )
> > > #define PLATFORM_ASCTOSTR( x ) ( x )
> > >
> > > is required because we deal with ASCII/EBCDIC rather than with real
> > > Unicode char sets
> > > So my strong suggestion is we need moving to use Unicode (with
> > > w_char) in place of bytes (char),
> > > esp. in the Axis lib - In stubs we might want to support by giving 
some
> > > functions to convert back and forth - or make call to a platform
> > > abstraction layer that
> > > we try to introduce here to make this conversion.
> > >
> > > Thoughts please??
> > >
> > > regards
> > > -Lilantha
> > >
> > >
> > > -----Original Message-----
> > > From: Nadir Amra [mailto:amra@us.ibm.com]
> > > Sent: Thursday, January 06, 2005 4:11 PM
> > > To: Apache AXIS C Developers List
> > > Subject: RE: Platform specific class
> > >
> > >
> > > Two things.
> > >
> > > First, the use of APR should be delayed until 1.6 or beyond because 
we
> > > have too many things we need to get done for 1.5, at least from my
> > > perspective. Major hurdle is I want to overcome is making code 
locale
> > > sensitive.  Adding APR to the mix would be too much to handle.
> > >
> > > Second, I do not think we can get rid of the platform header files 
that
> > > includes defines and typedefs, etc.  As far as making a platform 
class
> > > with methods to say load library, get locale, etc...my only concern 
is
> > if
> > > C code needed to access any platform-specific APIs.  I know the AXIS
> > > engine is purely C++, and if we can guarantee that C stubs do not 
need
> > > access, then I would say yes going to the class implementation, 
although
> > I
> > > am not sure it would not be overkill.
> > >
> > > I do not mind in 1.5 changing macros to functions if you feel it is
> > > necessary.  For example:
> > >
> > > In PlatformAutoSense.hpp, the APIs the platforms would need to 
implement
> > 
> > > would be listed:
> > >
> > > extern "C" platform_loadlibray( ...)
> > > .
> > > .
> > > extern "C" platform_unloadlibrary(...)
> > >
> > >
> > > And the implementation of the code would be in the separate files 
for
> > each
> > > platform, for example,
> > >
> > > \axis\axis-c\src\platforms\os400\PlatformSpecificOS400.cpp
> > > \axis\axis-c\src\platforms\aix\PlatformSpecificAIX.cpp
> > > .
> > > .
> > > .
> > >
> > > and in the ANT build, we can choose what platform cpp file to 
include
> > > based on platform.
> > >
> > > In addition, this could be a separate DLL so that we do not have to
> > > include in all DLLs used.
> > >
> > > Or, we can revisit this in a future release :-) and leave as-is. 
There
> > 
> > > is not that much in the files at this point in time.
> > >
> > >
> > >
> > >
> > >
> > > John Hawkins <HAWKINSJ@uk.ibm.com>
> > > 01/06/2005 04:58 AM
> > > Please respond to
> > > "Apache AXIS C Developers List"
> > >
> > >
> > > To
> > > "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
> > > cc
> > >
> > > Subject
> > > RE: Platform specific class
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Hi Lilantha,
> > >
> > > Good point - I'd forgotten about that project !
> > >
> > > Yes, the library routines there are exactly what we are talking 
about
> > here
> > > e.g. they have a getErrorMessage equivelant and most of the other
> > > functions
> > > that we have defined in our platform objects now.
> > > I can't see the equivelant of our ->
> > > #define PLATFORM_STRTOASC( x ) ( x )
> > > #define PLATFORM_ASCTOSTR( x ) ( x )
> > >
> > > in it but I might have missed it.
> > >
> > > If we were to use this library. We might still need some level of
> > > "Platform" object because our platform stuff has filenames in it 
(but
> > this
> > > is minor and is more architecture dependent than OS dependent 
between
> > Win
> > > and non-windows) and it might even be solved I perhaaps just didn't 
see
> > > the
> > > routine in the APR ?
> > >
> > > I'm worried about using APR because it's quite big and they say they
> > have
> > > compiled it on windows and Unix. This may have ramifications for us 
as
> > we
> > > support OS400  - Nadir - thoughts please?
> > >
> > > It would be a big move to use APR and it might be better to do it 
slowly
> > -
> > > if at all depending on the OS400 issue. If OS400 has issues with APR 
(or
> > > indeed other architectures/platforms) then we could have a 
compromise
> > (not
> > > a great one but a way forward) of moving to the platform model as
> > > previously described but making the base class use APR. That way any
> > > functions we had issues with or architectures/platforms that could 
not
> > be
> > > supported using APR could overwrite the methods.
> > >
> > > It's not great because it means that for every APR function that 
does
> > not
> > > work on all platforms we have to wrapper.
> > >
> > >
> > > Thoughts please folks?
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > John Hawkins
> > >
> > >
> > >
> > >
> > >
> > >              "Lilantha
> > >              Darshana"
> > >              <ldarshana@edocs. To
> > >
> > >              com>                      "Apache AXIS C Developers 
List"
> > >                                        <axis-c-dev@ws.apache.org>
> > >              05/01/2005 15:08 cc
> > >
> > >
> > > Subject
> > >
> > >              Please respond to         RE: Platform specific class
> > >               "Apache AXIS C
> > >              Developers List"
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > +1 for a Bridge pattern to support. PAL - Platform Abstraction 
Layer.
> > > Can we think of using APR (http://apr.apache.org/) for some of impl. 
?
> > >
> > > regards
> > > -Lilantha
> > >
> > >
> > > -----Original Message-----
> > > From: John Hawkins [mailto:HAWKINSJ@uk.ibm.com]
> > > Sent: Wednesday, January 05, 2005 6:38 AM
> > > To: Apache AXIS C Developers List
> > > Subject: Re: Platform specific class
> > >
> > >
> > >
> > >
> > >
> > >
> > > I was thinking of something like the following:
> > >
> > > (See attached file: Platform hierarchy.jpeg)
> > >
> > > As you can see the IPlatform interface has base implementations for
> > macros
> > > and pure virtual methods only. This makes it really clear what the
> > > platforms have to implement (with appropriate documentation at this
> > > level).
> > > The architecture layer (Windows, Unix etc.) then has platform 
specific
> > > implementations of the methods and any overriding of the macros that 
may
> > 
> > > be
> > > necessary.
> > > The platform specific layer (WINNT, AIX, HP_UX etc.) then has any 
more
> > > specific overrides that may be necessary over and above the 
architecture
> > > layer.
> > >
> > > The Platform factory is the key class it is set out something like 
this
> > > (Pseudo) ->
> > >
> > > class Platform
> > > {
> > >       static IPlatform platform;
> > > #ifdef WIN32
> > >       platform = Win32Platform
> > > #endif
> > >       /**
> > >       *
> > >       * returns the specific instance of Platform
> > >       */
> > >       static IPlatform getplatform();
> > > }
> > >
> > >
> > > Thoughts folks?
> > >
> > >
> > > John Hawkins
> > >
> > >
> > >
> > >
> > >
> > >              Nadir Amra
> > >              <amra@us.ibm.com>
> > > To
> > >              04/01/2005 18:44          "Apache AXIS C Developers 
List"
> > >                                        <axis-c-dev@ws.apache.org>
> > > cc
> > >              Please respond to
> > >               "Apache AXIS C Subject
> > >              Developers List"          Re: Transport specific class
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > I agree, and was thinking of doing that....although do we want a
> > > PlatformServices class or just individual APIs?
> > >
> > > Nadir K. Amra
> > > e-Business Technologies - IBM eServer i5/OS
> > > IBM Rochester, MN,  (Tel. 507-253-0645, t/l 553-0645)
> > > Internet: amra@us.ibm.com
> > >
> > >
> > >
> > > John Hawkins <HAWKINSJ@uk.ibm.com>
> > > 01/04/2005 12:40 PM
> > > Please respond to
> > > "Apache AXIS C Developers List"
> > >
> > >
> > > To
> > > axis-c-dev@ws.apache.org
> > > cc
> > >
> > > Subject
> > > Transport specific class
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Hi Folks,
> > >
> > > I've just been putting some error information into transport and
> > realised
> > > a
> > > few things. (I'm going to start another thread re other issue.)
> > >
> > > I just implemented a "getErrorMessage" piece of code which should 
have
> > > gone
> > > into the platform specifics but it was quite chunky and did not sit
> > easily
> > > with being a macro.
> > >
> > > The Platform specific files are not classes - this surprised me - 
would
> > it
> > > be better to have a platform interface that the specific classes
> > overrode
> > > with their implementation? I understand that the macros are probably
> > fine
> > > for most things but if we had a platform class it would be more 
explicit
> > > what each method had to achieve. These methods could also return 
values
> > > more explicitly?
> > >
> > >
> > >
> > > John Hawkins
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > 
> >

Mime
View raw message