On Mar 27, 2004, at 19:47, Ugo Cei wrote:
Torsten Curdt wrote:In general I agree but it makes the deployment more complicated because the authentication differs from container to container.
The container-specific part of the configuration varies, but it's usually not that complicated. And everyone who has ever deployed a J2EE webapp should know it well.
Anyway, the current implementation of authentication in Linotype is a toy, so you'd have to rewrite it for a realistic deployment, and whoever wants to deploy Linotype using a different user repository, LDAP for example, or support single sign-on, would have to rewrite it once again.
J2EE has a standardized, declaratively specified, authentication mechanism for web apps, that is good enough for Linotype and most apps. Why reinvent it?
Well, there is a big reason: ease of deployment.
Linotype will be block and people will want us to deploy a block and forget about it.
We don't spend 18 months of design to come up with something that is totally hotdeployable and rewritable and then you throw it down the drain because you have to restart the container because you have to add your own little thing in the webapp deployment descriptor.
Why reinvent what J2EE sucked at? well, I thought that was the reason to for doing cocoon in the first place.
I'm all for a better authentication strategy but if this doesn't work with our way of doing stuff, well, it's not going to help anybody.
We would need to maintain examples for the different containers... The login page might also need to be different per container.
We can easily provide a configuration for Jetty, since that's what we distribute for running the examples (I already did and will commit it soon). Adding another one for Tomcat wouldn't be a problem at all.
See, that's exactly what I mean.
I am talking specifically about a file-based user realm, no JDBC so there would be no dependencies.
WRT the login page, I routinely use the same page for Jetty and Tomcat, so I suppose it's standard. But you can always use BASIC authentication and do without a login page.
But wouldn't this limit us to the particular "features"/stuctur of that
markup. (Well, except using a different namespace) And what is the
benefit? We could save a transformation.
Atom (and I think also RSS 2.0) can be extended with elements from other namespaces, indeed. And we could also ask for changes to the Atom spec, since it's still in draft stage. Anyway, what do you suggest that we use as an alternative?
There is no need to use a standard markup for something that nobody is ever going to see. I'm happy to move to a more cocoon oriented namespace and move away from my own, but I don't see the need for use a markup that was invented for feeds and not as a storage markup.
-- Stefano.
