Just my 2 pence worth (as an apache/tomcat admin in a large company); > >>>- the configuration should be in Apache's config file, rather than > >>>some complex properties file > >> > >>+1
Yes please! > > The general idea is to connect to TC and get the URI/VHOST > topology, but we > > still need the 'intervene' directives for connector specific ones. > > How to make them simpler to use the JK and JK2? > > > > Perhaps using something like: > > > > <CoyoteWorker workerA> > > ...directives > > > > </CoyoteWorker> > > I agreed for this on worker configuration in httpd.conf. > > > And then: > > > > <Files *.jsp> > > CoyoteUsesWorker workerA > > </Files> > > ok. > > We should also be able to handle : > > <Location /myspecialurl> > CoyoteUsesWorker workerA > </Files> > > Something very familiar to Apache admins. > Excellent point in that it needs to be similar to other apache directives. > >>>- it should work well with other modules (I guess if somehow it is > >>>accepted into the Apache codebase, it will be required) > >> > >>That's why we should focus on Apache 2 only module. Hum, but > > > > Not sure I'm in favor of that (unless you meant dropping > 1.3 module by > > that). > > Of course, I want a module designed for Apache 2.x (2.0/2.1). > Apache 1.3 > could live with jk 1.2.x. IIS/NES/DOMINO could use jk 1.2 or jk2. > No more code complexity to handle all the web-servers around, > we should focus on Apache 2.x. > > For example majors Linux distributions are now using Apache 2 > instead of > Apache 1.3. So Apache 2.x will be more and more used. true. But from experience most admins will not use the vendor (Sun/Redhat/IBM etc ...) supplier widget as this widget is subject to a vendors patching schedule. Hence most admins install their own version outside the normal file system hierarchy. So, be in mind that people like me still use 1.3 for many reasons, although some have moved to 2.x. What I am trying to say is that do not dismiss 1.3.x unless it is difficult to include. > >>>- I think the protocol should be an extension of AJP/1.3 > >> > >>I proposed eons ago, AJP/1.3 extension, called AJP/1.4 and it > >>could be a good candidate. In my idea we should start to > >>write an APR based > >>AJP/1.4 library, which could be first used outside Apache 2 > >>server for test and benchs purposes. > >> > > > > > > +1, but in contradiction with previous :). > > I would also like to see the gzip like extension to AJP/xx > for lowering the > > data transfer. > > It was proposed some times ago together with some light > crypto to secure > apache - tomcat link when you're not in a secure network. All > of these > could be made optional in protocol negociation side of AJP/14... Crypto and compression would be a very good addition - although not to ignore the simple connection as it needs to be quick/efficient! Greg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
