axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lilantha Darshana" <ldarsh...@edocs.com>
Subject RE: Platform specific class
Date Tue, 11 Jan 2005 00:03:55 GMT

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