commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <mdigg...@latte.harvard.edu>
Subject Re: jakarta-commons-daemon could use that ?
Date Mon, 10 Mar 2003 15:30:15 GMT


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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message