On Fri, 21 Dec 2001, Craig R. McClanahan wrote: > As appealing an idea as this sounds (packaging plug-in modules as > webapps), it doesn't solve the underlying issue -- different containers > have radically different internal architectures, and packaging the plug-in > as webapp doesn't avoid having to deal with that. You still have to > bridge the architectural differences for "installing" the plug-in > functionality in the container, using container-specific APIs.
Except that 'packaging' of the module doesn't even try to solve that problem ( of different internal architectures, etc). The problem it tries to solve is simplifing the live of the user, who will use the ( hopefully ) simple pattern of deploying and configuring web applications. If a container's architecture allow certain functionality ( whatever that is ) - we'll try to take advantage of it, and make the connector aware of it. If not - then that feature will not be available on that container. We don't try to create a common API or a meta architecture - just to take advantage of the maximum set of APIs and features a container provides. > To be successful at bridging this gap, you've really only got a couple of > choices: > * Create an external common API for things that are not architecture > dependent (like web connectors) that a container can choose to > support or not support, and don't bother trying to standardize > things that are radically different between architectures (for > example, RequestInterceptor vs. Valve, or the very different > concepts of how the core components of the container are organized). That assumes the container should ( or should not ) support a particular API or connector. IMHO the connector is a module that should support different containers by using their APIs. It's unlikely IIS or iPlanet will start supporting jk. And I see no reason for 3.3 ( for example ) to be changed to support whatever internal API the connector will use on the java side. On the other side, jk should try to use whatever API the web server ( on one side ) and servlet container ( on the other ) provides. If certain things are possible only with Apache2 ( like dynamic configuration of the server using the cfgtree ) or a container - we should use them in that particular case. If not - we can either try to provide a workaround or just document that this feature is available only with a particular configuration. > * Create a meta-architecture (via a set of common APIs) that all > containers must support -- never mind that it might mandate doing > things in a totally different way than any existing container. Again something that wouldn't make sense - the role of the module is to augment the functionality, not to dicatate a particular API or model. > IMHO, the latter option is not practical. Packaging plug-in functionality > as a web app does nothing to help resolve the basic issue that containers > are different on the inside. And, if you went to the effort to do this, > you'd spend your time more efficiently by just creating a container > conforming to those APIs and be done with it. Packaging the plug-in as a webapp doesn't try to resolve that problem ! Containers and web server are different on the inside, and that's not even something bad or a 'problem' that needs to be solved. Packaging the plugin as a webapp is intended for the users deploying or using plug-ins - if a particular plugin has support for a container, than the user's experience will be consistent ( not the complete set of features the plugin can provide - that depends on the container's architecture - but the basic functionality and problem the plugin is supposed to solve ). > Oh wait ... we've already done that ... twice :-). That seems entirely > sufficient to me. I think it have been done few dozen times - and there's still plenty of space for improvements :-) Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
