Hi, Since I've started few months ago all the C++ fuzziness (I did posted even some source to Costin back then), my intention wasn't to CPP-ize the existing code, but rather to move that 'dead' code on some new tracks.
What I'm looking since then is some kind of different approach to the subject. I'll take a good look at javagroups. Seems to me that this is something that I had in my mind for a while, meaning leaving all the communication and configuration to some Java proxy, and having native only to communicate with that proxy. What I was looking at was the way to find the 'more intelligent' way of integration, definitely having GUI (html) configuration, something like TC Manager, and cacheable configuration on the native side (today's jvm's are IMO quite different with native integration then 1.2 was back in days when JK2 was started). The native part would have to be as simple as possible, having only the jvm and classloader, and few native calls, allowing it to be integrated not only in Web server, but with the simple console client too. I agree with you that this would be JK3, rather then JK2 on steroids :-), and it would require a different perspective. I'm in favor of _usability_ over performance in that new approach. The major question is are there any developer interest on that? Also I wouldn't like to been seen as 'a JK2 killer', but if we are frankly with ourselves, there wasn't a major JK2 technological advantage for more then a year, and there isn't much interest of the developer community thought. I also use the JK for production servers, and it is doing just fine for what it needs to. MT. > -----Original Message----- > From: Henri Gomez [mailto:[EMAIL PROTECTED] > Sent: 8. siječanj 2004 9:54 > To: Tomcat Developers List > Subject: Re: Jk2 object model > > > I'm pretty busy these days so I can't works on JK2 as I want to. > > > > Some ideas/reflexions. > > > > JK2 is very similar to JK, from the tomcat point of vue, since the > > same ajp13 protocol is used, and may be in such case we > could see JK2 > > too similar to JK to see users switch to JK2 (for instance > we're still > > using JK in-house). > > > > In thread I read some says that JK2 is allready dead, and in such > > case, using JK2 to make what JK does, it may be true. > > > > I'm working on an in-house project were I'm using jchannels to make > > some applications works with cluster of service servers and > that's an > > idea which could be fine for JK2, or JK2++ or JK3. > > > > Using this kind of high-level communication channels help make > > automatic clusters, without the need on the client (on our case > > Apache/IIS) to know the topology. > > > > I didn't know if a native (C/C++) jchannel implementation > exist but if > > we could find one, I think we should think to use it to > make JK2 more > > that just JK++. > > > > The benefits are enormous, automatic detection of tomcats > when added > > or removed from the group, determination of webapp/url > which could be > > handled.... > > > > > > What about ? > > Oups, you should read javagroups (http://www.jgroups.org) in > place of jchannels ;) > > JGroups is really a great piece of code but miss native code > implementation. > > But the idea is here, and if we could find the same kind of > code with native and java implementation, we should take a look at it. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
