Cheers, Mark
Greg Guerin wrote:
Mark et al.
Please leave me out of these discussions. I have no side to take, and no agenda to push.
If you decide to use Easy Posix Toolkit, that's fine. If you decide not to, that's fine, too.
If you write a JNI implementation for Linux, I'd like to hear about it. If you don't, then I guess I don't need to hear about it.
Thanks for your consideration.
-- GG
jean-frederic clere wrote:
Mark R. Diggory wrote:
Cygwin supports a wide array of posix functions, and making sure the
implementation of EasyPosix that worked on cygwin as well would
provide a port of these functions to Windows via Cygwin.
I am afraid that is not a very accepted solution. jakarta-commons-daemon (service) uses Cygwin and a lot of people were complaining about that.
I can see why Windows developers would complain; Cygwin isn't very popular with them because it�s so "divergent" from their "paradigm". I wouldn't suggest it if it weren�t that its almost the cases that if it runs on Unix, it will run on Cygwin with just a little modification. I never understood why someone would want to run Windows as a server, but I'll avoid any Windows OS bashing as I'm typing this email on one at the moment and that would seem hipocritical. ;-)
Apache has an already portable runtime: APR. It would be probably more
efficient to bring an APR interface to JNI than to use a new runtime.
And that is already some code in jakarta-connectors.
YES, Yet anothor reason to consider another "layer" similar to EasyPosix for daemon and other services requiring the native OS access to run upon. Then you can have one implementation of daemon/connectors that can run on multiple implmentations of Easy-Posix. This is a case for mapping a set of Easy-Posix commands/functions through the APR as well. Consider that there may be a *Union* of shared functionality currently captured through JNI --> APR, JNI --> Ten and JNI --> Posix.
What I'm suggesting is not to "isolate" the daemon service to one particular native solution. By adding a layer of "OS functionality" between the OS and the daemon, the daemon can stay a conceptually simple interface/implementation and the *functionality of the OS* can be captured at the *level of its functionality*, making it possible to "extend" that functionality across different systems without many different versions of daemon (which is a tiny subset of that functionality). In theory, what we are talking about is a means to "extend" the JVM's capabilities at the level of *that native functionality* making its capabilites available across all current or new projects that may be depended on it, instead of at the level of each project.
I've considered this results in further "Balkinization" of the Commons code base, But I've come to the conclusion that it is more a "reorganization of functionality". Its recognizing that there is a set of "native" functionality that is used across Jakarta and reorganizing that use into a subproject that is "clearly focused" and with "strong interface boundaries".
What do you think of it ?
-Mark
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
