> -----Original Message----- > From: Remy Maucherat > > > > The only 2 JNI models that actually work are jk2 "protocol > > marshalling, pass only byte[]" and eclipse swt "small simple calls > > with mostly int and byte[] params" > > > All that is cool, but what you propose looks a lot like JK 2 > (JMX dynamic features, support for many webservers, etc), and > we know that almost no developer understands it anymore. This > clashes head on with the "it has to be simple" requirement: > how do you expect the issue to be solved ? > > This is the point about dropping server portability, among > other things. > Sorry to say it aloud, but for new developments I don't care > about IIS (it should die) nor Apache 1.3, which are the two > other servers that matter. To support these, we have mod_jk > 1.2 (and too bad if people don't get the extra features). >
I agree with you. We've tried to hard to mix a bunch of different concepts together. At some time the JNI even worked, but only on single-child servers (Apache2 on Win32 and IIS). IMO we should focus on the 'APR/APR-UTIL' based protocol and TCP/IP transport for now, with in memory config dynamically updatable via API calls, using as little as possible specific 'ap_xxx' calls. I like the Henri's idea to have a little lib and a small app like ab, to test the protocol, and all core functionality. It would be a tremendous achievement to be able to effectively test the core module functionality without server itself. It would give a common playground for protocol testing, auto-config, etc... The JNI is totally different, cause you can have only one VM per Apache2 instance, but you can have 100+ forked childs each trying to load it's own VM, so the inprocess TC instance has a very limited usability, and is very server specific. IIS is also something different, and if one wish to write the good extension it has to be done in a different way. Still, some core functionality can be reused, but not making some 'common' code, but rather making common codebase, that some inexperienced (in a JK/JK2 sense) developer will be able to cope with. I agree with Costin that the JMX is a great stuff, but not if we wish to build a simple and _reliable_ module with finite (or static like Costin said) set of functionality. The AJP13 protocol will have to be enhanced (or better enabled) to use the 'Service channel' and 'Data Filter'. It is not necessary to define all Service channel modes like server topology, or server readiness, neither to define all the Data Filter modes like cryptography or compression. I was thinking of something like 'extensions' to the protocol, meaning that one can extend the protocol to some desired level. MT.
smime.p7s
Description: S/MIME cryptographic signature
