Developer and Deployment Concerns

[Berin Loritsch <bl...@apache.org>]

<unrelated>I would really like to see dev@cocoon.apache.org</unrelated>

With the view related security issues that have arrisen, we have to look
at some realities of development and deployment.  They have some
potentially conflicting concerns.

Developer Concern #1:

    A developer needs to have all the information available to them to
    allow them to debug and correct mistakes.  Part of that also include
    needing development time functions to clear the cache, or have the
    system reload from scratch.  Not to mention the developer needs to
    be able to look at the various log messages and runtime internals
    as best as is possible.

Deployment Concern #1:

    Deployment must have the most stable and predictable environment as
    possible.  That means as long as the client (the site's user in this
    case) can only interact with the server in a very limited way.  In
    no way should a client be able to do all the things listed for a
    developer to do.

Developer Concern #2:

    Developers need flexibility.  They don't want to be locked into too
    small a box.  They need to try different approaches and compare more
    than one similar way of doing things.

Deployment Concern #2:

    Deployment needs stability (just like concern 1).  Nothing can
    can change.  Once its deployed its deployed.  The only things that
    should be dynamically happening are data releated, and already well
    understood.


What does this mean for Cocoon?

#1) Views expose necessary functionality for developers, but alot of
     potential abuse for deployment.

#2) XSP is a great tool for development, but nothing should be dynamic
     in deployment--esp. logic.


What do we do about it?

There are a couple paths to go down.  The first path is generative
programming.  IOW, Cocoon is just another way of generating servlets
that are powerful and collaborative.  No logic is dynamic when the
site is deployed, but it is during development.  The second path is
to use aspects (not necessarily AspectJ, but using the same principles).
Developer concerns are applied during development--but removed for
deployment.

Both require work, and probably shouldn't be started before a 2.1
release.  In the past I favored the first option.  I mean once a
site is generated its generated.  The problem is debugging.  What
happens when the generation process introduces errors or artifacts
that were not there during development?  It's not pretty.

I favor the aspect oriented approach.  This would require the ability
to abstract certain functionality for Cocoon into aspects.  Things
like clearing the chache, forcing refresh, or selecting view.  The
Cocoon system needs to know how or when to apply these concerns.
These concerns should also be placed in an external JAR.  When the
jar is removed, the concerns are never applied.

Re: Developer and Deployment Concerns

[Sylvain Wallez <sy...@anyware-tech.com>]

Berin Loritsch wrote:

> <unrelated>I would really like to see dev@cocoon.apache.org</unrelated>
>
> With the view related security issues that have arrisen, we have to look
> at some realities of development and deployment.  They have some
> potentially conflicting concerns.


This reminds me of a discussion back in september (see [1]) about 
running modes. Some of the concerns you address can be solved by having 
various components adapt their behaviour depending if Cocoon runs in 
development mode or in deployment mode, and thus providing more 
"unsecure" features at development time while being more strict at 
deployment time by just changing a flag in a configuration file.

Sylvain

[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103175546321320&w=2

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }