cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject XSP block (was: Type 'serverpages' does not exist for 'map:generate')
Date Tue, 10 Jun 2008 03:27:08 GMT
Moving this discussion from users list (for reference [1]) to dev list.

On 06.06.2008 19:02, Alfred Nathaniel wrote:

>> Warning: I'm stating my own opinion here, nothing official or something like that.
>> There are at least three problems with XSP:
>> 1. No active committer is interested in XSP anymore, and even more, hardly anyone
wants to invest 
>> her time in technology that seems to be deprecated in every dev's head but still
block is not 
>> officially marked as deprecated.
> I may be not as active as you but I am a committer who is still very
> interested in XSP.  In may daytime job we have 1000+ XSPs in production
> and no intention to drop that technology in the forseeable future.  XSP
> has its shortcomings and pitfalls but after 7 years experience we know
> how to handle that.
>> 2. The only reason why people keep trying to use XSP is that it has decent documentation
on our site 
>> and this documentation has no information about XSP status. We should really explain
people that 
>> Templates + Flowscript is much better approach.
> I think the reason why XSP appeals to newcomer is that the concept is
> familiar from JSP, and it is a combination of the three core
> technologies which Cocoon handles extremely well:
> XSP = XML + XSLT + Java.
> Personally, I still do not consider Flowscript an alternative for
> enterprise websites for three reasons:
> a.) Serverside JavaScript is an additional level in the technology stack
> you and your team have to master.
> b.) I would not bet my head on Rhino being threadsafe, and it is such a
> big beast to debug it yourself.
> c.) Continuations are a great idea, but how do you know when it is safe
> to free the memory?
>> 3. XSP is really old technique and is not maintained by anyone (again officially,
at dev/commits 
>> list). I'm not the one willing to take costs of XSP maintenance in C2.2 therefore
I'll probably vote 
>> -1 for any actions leading to release of XSP block for C2.2. This is my first such
a strong voice in 
>> this case but I firmly believe it's a high time have a concrete opinion.
> XSP is a really mature technology which hardly needs any maintenance any
> more.  The reason why the XSP block (as many other blocks) is not
> released yet is actually more of a C2.2 issue than an XSP problem.
>> Still, I'm open for discussion of course.
> I'd prefer to have this sort of discussion on the dev-list.

I completely agree with Alfred. I don't see any reason for not releasing 
XSP block. Yes, somebody has to do the actual work. But why blocking it 
when somebody puts in the effort? You can estimate the maintenance costs 
by looking at the changes in the last years in the 2.1 branch.



View raw message