> 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 <[EMAIL PROTECTED]> 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 > <[EMAIL PROTECTED]> > To > 12/01/2005 06:58 "Apache AXIS C Developers List" > <[email protected]> > 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" <[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 > > > > > > > > > > > > > > > > > >
