Lilantha, I assume you are agreeing with me? That is, these should all be objects with methods, not one big class with single calls.
John, I prefer my implementation since these mutexes, threads, sockets, are classes with methods. Each should be self-contained. The implementation does not preclude you from inheriting from the default implementation and implementing or extending a class. More in-line with object oriented coding. I would agree with your method if it was simply one-time function calls to achieve something. But that is not the case for mutexes, sockets, etc. Nadir K. Amra "Lilantha Darshana" <[EMAIL PROTECTED]> wrote on 05/20/2005 01:16:43 PM: > I think this is what we discussed when we were originally discussing > this idea ? PAL > I believe, object oriented model is the way to go. > > Additionally layered architecture simplifies the design. As if we > follow the following model of layering. > Here, zero-th layer is the platform abstraction layer. > > > 3 > > Service > > Axis engine etc > > 2 > > common > > General - broadest applicability that helps Axis engine e.g. XML parsing > > 1 > > Language > > Code that effectively extends C/C++ (e.g. extending string operation > functions or way to handle introspection in C++ etc.). > > > 0 > > Environment or platform > > Per environment/configuration (PAL ? Platform Abstraction Layer) > e.g. specializations to support: > mutexes, library loading, socket/stream, memory management, > error/signal handling, threading etc. > > > > > thanks > -Lilantha > > From: John Hawkins [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 19, 2005 5:45 AM > To: Apache AXIS C Developers List > Subject: Re: Platform abstraction layer thoughts > > > Ohh - hadn't thought of creating classes for the functions. > > I'd thought that we'd have classes for each platform and those > classes would have methods for the function e.g. > > PlatformSpecificWindowsUtils > #doMutexStuff() > # getErrorMessage() > > etc. > > Then we would have a hierarchy of PlatformSpecific classes as in the > attached file. > > This would mean that if all Unix platforms are the same then only > the base UnixPlatformSpecific class has to implement it. > > > > > This model still gives the ability to override the methods with APR > or non-APR versions. > > I think we've fundamentally got the same idea but you're making > functions the classes whereas I'm putting the function into platform > specific classes (which happens to be more like what we have today). > > > > > > > > > > > > Nadir Amra <[EMAIL PROTECTED]> > 18/05/2005 22:33 > > Please respond to > "Apache AXIS C Developers List" > > To > > [email protected] > > cc > > > > Subject > > Platform abstraction layer thoughts > > > > > > > > > > > My thoughts on the platform abstractions layer is as follows. Note that I > will initially focus on the client-side of things, but I hope to also > eventually get to the server side to see what needs to be abstracted. > > Just to level-set, the goal is to attempt to concentrate as much as > possible any platform differences in one area - code will be located in > the platforms/ directory. There occasionally will be times when this > cannot be done, but hopefully those occasions will be few and any > platform-specific code changes required outside of platforms/ directory > will be minimal. > > I have initially identified several areas that need to be abstracted: DLL > loading, mutex, socket, and obtaining OS errors. There may be more (such > as event log for FFDC kinds of stuff - on Unix maybe syslog() will be > used, on windows to the event log), but that will be identified and done > later. > > The idea is to have classes for the various platform-specific stuff. The > header files and default implementation would be in platforms/ directory > as follows: > > platforms/AxisPsLibraryLoader.hpp > platforms/AxisPsLibraryLoader.cpp > platforms/AxisPsMutex.hpp > platforms/AxisPsMutex.cpp > platforms/AxisPsSocket.hpp > platforms/AxisPsSocket.cpp > platforms/AxisPsOSError.hpp > platforms/AxisPsOSError.cpp > > The default implementation of these classes will be patterned after Unix > and packaged in a DLL/share library called, for lack of a better name, > axis_platformservices.so. The AXIS engine will need to link to this > DLL/shared library and thus it will need to be created first prior to > creating any other DLLs/shared libraries. > > The implementation code for other platforms will be in each platform > directory. For example, OS/400 will need to have its own > AxisPsLibraryLoader.cpp file so one will be located as follows: > > platforms/os400/AxisPsLibraryLoader.cpp > > When building the axis_platformservices DLL/shared library, which files > are build is dependent on the platform. For example, OS/400 would build > everything in platforms/os400/ and would also build > platforms/AxisPsMutex.cpp, platforms/AxisPsSocket.cpp and > platforms/AxisPsOSError.cpp. > > The creation of the classes and implementation will be done as part of > stage one. I will also attempt to modify the ant build scripts to build > the DLL/shared library. However, I have no expertise with makefiles so > someone would need to do that. Stage one would just be putting the stuff > in CVS and for all of you to look at and comment on. Everything should > still build as it does now. > > Stage two would be to change the Axis engine to use the above classes and > link to the service program. Again, someone would need to volunteer to > update makefiles. At this point in time the ant build would work but the > make would fail unless someone updates the makefile. > > For stage three, if we still want to go to APR, the default implementation > can be changed to use the APR APIs, and if a platform wants to go that way > they can, otherwise, a platform can still have its own implementation of > the classes. This will protect platforms that may not have all the APR > APIs, or do not have APR at all. > > So what do you think? > > > > Nadir K. Amra > _______________ > Siebel > IT'S ALL ABOUT THE CUSTOMER > Visit www.siebel.com > > This e-mail message is for the sole use of the intended recipient(s) > and contains confidential and/or privileged information belonging to > Siebel Systems, Inc. or its customers or partners. Any unauthorized > review, use, copying, disclosure or distribution of this message is > strictly prohibited. If you are not an intended recipient of this > message, please contact the sender by reply e-mail and destroy all > soft and hard copies of the message and any attachments. Thank you > for your cooperation.
