Hi Felix,
- request handling
- error handling
We have both, right ?
Right. And this is great.
- request filtering
- response filtering
There is no difference in request and response filter - there is just
filtering. Currently we implement this by requiring the registration
of
request-level or resource-level filters.
The problem with filtering is, that it imposes certain performance
degradation. So if you (or Michael) would be able to present a
conceptor
even a patch, we may certainly further discuss.
Let's start with a concept, then a patch and then care for
performance. No premature optimization.
- repository events
This sounds, easy to implement, though there are certain ACL related
open issues: What credentials are active for the scripted events ? Who
is allowed to post scripted JCR event handlers ? In fact this has
already been discussed [1] to a certain degree but without reaching a
final target...
Everybody who can create scripts or servlets is allowed to post
scripted event handlers, a simple ACL on the events-tree is enough.
The event is executed with the credentials of Event.getUserId().
- timed events (cron jobs)
Carsten ?
are scriptable. I think this is a reasonable request and would allow
users to build powerful web applications in the script language (or
even servlets) they prefer.
Well, I think, there are things, for which scripting is very well
suited
- such as processing GET requests - and other things where scripts are
not actually adequate. So to build powerful applications, scripting
may
certainly be used, but over time, you may realize, that the scripting
language of your choice might simply not be adequate.
Right. But this realization should come from the user, not from the
framework that says for this certain feature, you have to forget
everything you learned about scripting and start using an IDE, Maven
and OSGi, even if you just want to implement a small filter that
validates your request parameter or overrides the content-type-header
in the response.
And to just use
scripting, because for a given limited tool it is the only way to
"extend" it, is probably not right solution. I would suggest to move
to
Sling in this case. Just my very personal €0.02.
Right. But moving to Sling, should mean chosing the Servlet
implementation voluntarily over the script implementation. This
separation between Sling and Microsling will not prove helpful if we
do not understand that Servlet and scripts are two different, but
equally valid expression of one of the concepts listed above.
Lars
[1]
http://www.mail-archive.com/[email protected]/msg00948.html
--
Lars Trieloff
[EMAIL PROTECTED]
http://weblogs.goshaky.com/weblogs/lars
