Hi,
I'd like to reactivate SLING-5884 and a related discussion [1] we had
about deprecating the query part of the Sling Event API.
TL;DR: Open question is exactly which of the JobManager methods do we
want to deprecate.
The idea is to deprecate (and sometime in the future - timing tbd -
remove) those methods of the sling event api which we either consider
expensive to support (eg maintaining large indexes for queries) or
making assumptions/limitations on the underlying implementations and
thus prohibit usable alternative implementations such as messaging-based
ones.
Now to the discussion as to what exactly we want to deprecate and how we
see alternatives (or not) for each (all methods of JobManager [2]):
(A) addJob, createJob: Those must stay
(B) getQueue(s), get(Topic)Statistics: Those can probably stay
(C) getJob, findJobs (and QueueType): those are the main query methods
that should be deprecated. We'd not provide an alternative, but could
suggest those who want to maintain job information could do that
themselves in a shared place.
(D) getJobById, retryJobById: both assume some kind of job storage that
can be accesses in an arbitrary way. Thus I'd argue both could be
deprecated. Alternative suggestion similar to (C). Edge-case.
(E) removeJobById: can imv stay. the api makes no hard requirement to
check if the job ever existed, however it requires that the job be
removed when returning true, so requires (expensive) synchronicity.
Doable. Edge-case.
(F) stopJobById: can imv stay.
(F) getScheduledJobs: while this requires some form of job storage it
only affects a small amount of data. But if we'd want to make the job
api messaging-ready it would also have to be deprecated. Edge-case.
Cheers,
Stefan
--
[0] - https://issues.apache.org/jira/browse/SLING-5884
[1] - http://sling.markmail.org/message/k3hjqcvnnabsb47j
[2] -
https://github.com/apache/sling-org-apache-sling-event-api/blob/master/src/main/java/org/apache/sling/event/jobs/JobManager.java
