cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Linotype
Date Wed, 31 Mar 2004 15:06:58 GMT

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.


Mime
View raw message