cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject [RT] pipeline aspects
Date Sat, 22 Mar 2003 09:38:02 GMT
Geoff Howard wrote:

> Obviously, if my 
> application doesn't use any uploads I should disable them in web.xml.  
> But right now, it's all or nothing: I either allow all users to upload 
> _on any page_ (if they create a form that posts to any url in cocoon's 
> space), or I totally disallow uploads.  I've been thinking through 
> enabling configs for resource-based, or even authentication-based 
> restrictions for uploads.  What would others think?

I've been thinking about this for a while and I thought about waiting 
for 2.1 before sending these RT, but I just wanted to introduce them 
briefly before a quick-hack solution is implemented.

In my continuous quest to see if our pipeline architecture is enough for 
even the most complex web needs, I found out that it is not always the case.

After we release 2.1, I will introduce a discussion about "pipeline 
aspects" in order to suggest a more elegant approach to:

  - handling webdav
  - handling uploading
  - handling views
  - handling proxying
  - handling chunked encoding

In short, all those behaviors that require deep contact with the 
internals of the HTTP stream both in reading and writing and, 
potentialy, from all the pipeline components.

The way we designed the pipelines was mediated out of the servlet API 
and the servlet API was designed exactly to prevent you from having to 
know (or manage) the HTTP internals.

Since the approach was a very useful one (in short, clean IoC applied to 
the HTTP paradigm), we designed the environment in that direction.

But we have one major difference between the servlet API: the API is 
designed so that one or more web resource is associated to one (or, 
using request dispaching, a procedural chain of) programmatic request 
handlers (the servlets or the jsp pages).

Our model is entirely different and it's pretty rare (see readers) that 
we have only one request-handling component that touches the request.

Cocoon aims at complete and clean SoC and started for publishing needs 
(stateless, GET-driven). We achieved that with the sitemap. Then we 
moved into webapps (stateful, GET/POST roundtrip driven). I think we 
solved all possible issues with the flow.

The question I posed to myself was: now that we have both pipelines, 
sitemaps and flows, are we able to handle the complexity of WebDAV in a 
clean way?

The answer is, unfortunately, "no".

Don't get me wrong: you can write a cocoon-enabled webdav-app 
(webdav-apps are webapps that use not only GET/POST but all the webdav 
extension to the HTTP protocol!) even with 2.1 but it won't be so clean.

why?

well, unlike GET/POST actions which inherently assume a 
resource-oriented granularity, there are other actions (and I consider 
the cocoon view a special case of HTTP content negotiation) that require 
'cross cutting' behavior across different resources.

I think the sitemap semantics is inherently great at describing concerns 
that can be well separated (using matching, for example) but very poor 
at describing crosscutting concerns.

Examples of crosscutting concerns are:

  1) webdav enabled
  2) restricted/protected
  3) proxiable
  4) viewable
  5) upload handling
  6) pipeline-wide global parameters

There is no single mechanism to handle all those.

Views have a special semantics. Upload handling is made *explicitly* 
cross-cut across the entire domain space (and this is, rightly, a 
potential vulnerable point, expecially if associated with resource 
restriction).

The best example of crosscutting concern is Restriction/protection: this 
is most elegantly done (currently) with wrapping a map:mount.

I wonder is this is, architecturally, the best approach.

In theory, it should be possible to define 'behavior modifiers' that 
wrap pipelines and transparently provide different behaviors to them.

I see two possible approaches:

  - external modification
  - internal modification

external modification is done with wrapping a mount, like we do today 
for restricting access to an entire sub-sitemap.

internal modification is done for views, but this required a special 
semantics added to the sitemap and, in retrospect, it seems to me that 
it was a mistake.

We can't use Actions or flow to modify pipeline behaviors unless we give 
full access to the underlying object model, opening the gates for abuses.

We can't add the possibility for people to add their own sitemap 
semantics, or we have the same abuse problem.

I see two possible solutions, depending on where we want to go:

  1) create a 'wrapping' component

or

  2) add the ability to add pluggable <map:pipeline> metadata without 
exposing hooks for internal pipeline abuses.

Note that these are very random thoughts and I don't have a coherent 
view of what we need and how we solve those issue. at the same time, I 
think it's worth thinking at those pipeline-wide problems with little 
aspect orientation in mind.

Stefano.


Mime
View raw message