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" <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> > 01/06/2005 04:58 AM > Please respond to > "Apache AXIS C Developers List" > > > To > "Apache AXIS C Developers List" <[email protected]> > 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" > <[EMAIL PROTECTED] To > > com> "Apache AXIS C Developers List" > <[email protected]> > 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:[EMAIL PROTECTED] > 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 > <[EMAIL PROTECTED]> > To > 04/01/2005 18:44 "Apache AXIS C Developers List" > <[email protected]> > 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: [EMAIL PROTECTED] > > > > John Hawkins <[EMAIL PROTECTED]> > 01/04/2005 12:40 PM > Please respond to > "Apache AXIS C Developers List" > > > To > [email protected] > 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 > > > > > > > >
