I think you're possibly more right than me ;-) I guess one does say "get me a Mutex" rather than saying "Get me a platform object and then get the mutex for that platform".
| Nadir Amra <[EMAIL PROTECTED]>
21/05/2005 21:44
|
|
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.
