Jukka Zitting wrote:
Hi,
It always makes sense to abstract things like the uses scheduling library;
this allows to change the implementation without breaking contracts.
Or YAGNI, and adding the abstraction just introduces extra complexity
and potential bugs.
This depends, creating an abstraction makes sense if you create a
framework providing special services - for long term solutions running
for years this makes sense (see Spring and their philosophy).
For implementations this might be yagni.
> Are there potential cases where Quartz wouldn't be
appropriate for a Sling deployment?
You can't just use quartz by calling some methods, Quartz itself
requires some infrastructure like thread pooling or persistence stores
(which we don't use) etc. So it makes sense to keep this initial stuff
at a central place anyway. You definitly don't want that everyone who is
scheduling something, does this stuff on their own (and possibly
differently). This creates too many problems.
I'm just looking at the scheduler code and all I'm seeing is wrapping
around Quartz. If the purpose is to provide a nicer API for
applications, shouldn't we be contributing that as an improvement to
Quartz?
Sure, that's always an option.
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
