Let me get something started and see where that leads us...we should be able to contain it for 1.5, as long as someone can do the makefile modifications....
"Lilantha Darshana" <[EMAIL PROTECTED]> wrote on 01/13/2005 12:17:11 PM: > Yes, lets delay the APR usage to later version. > > However, how much time you think it would take impl., integrate and > test only the OO model (PAL) with > required functionalities we needed? > regards > -Lilantha > -----Original Message----- > From: John Hawkins [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 13, 2005 5:16 AM > To: Apache AXIS C Developers List > Subject: Re: Fw: Platform specific class > > 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 <[EMAIL PROTECTED]> 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 > > <[EMAIL PROTECTED]> wrote: > > > > > > > > > Hi, > > > The generated C stubs can be compiled with a C compiler and willnot need a > > > C++ compiler. The C support is being separated out from the AxisC++ 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 willonly 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" > > > <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" <[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 toimplement > > > > > > > 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" <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 doit 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" > > > > <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:[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" > > > > <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: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > John Hawkins <[EMAIL PROTECTED]> > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
