One more thought, which has been discussed offline earlier:
While it might take a while to agree on the deprecation and on how we
recommend them to be replaced, there is a short-term option that would
already help lower load on systems:
We could introduce a config option which would allow a job queue to
opt-out of job queries voluntarily. That would allow the implementation
to treat those jobs differently (cheaper, without indexing them).
I guess such a new opt-out of queries mechanism could be less
controversial and provide at least some short-term gain. It doesn't
answer the question how job queries should be replaced though..
Cheers,
Stefan
On 17.12.18 14:02, Stefan Egli wrote:
Hi Roy,
I think removal of the job API hasn't been discussed much yet, so
that'll probably first have to happen separately.
Re deprecating the job queries: I think we should better understand the
use cases for doing these queries. Why is it not possible to fire a job
and forget, and why are queries needed/used. Ideally there would be an
alternative data structure (eg the data the job operates on) which would
be queried instead of the job itself.
Cheers,
Stefan
On 15.12.18 18:39, Roy Teeuwen wrote:
Hey guys,
Seeing as you are all talking about deprecating or even removing the
entire Sling Job API in the future, what would you propose as
alternative / migration path? We have a lot JobConsumers in our
projects, what would be a reason to stop using them?
Greets,
Roy
On 30 Oct 2018, at 11:27, Stefan Egli <stefane...@apache.org> wrote:
On 30.10.18 10:22, Bertrand Delacretaz wrote:
Hi,
I agree, and we might use the following trick to avoid that with
minimal disruption:
-Consider the current interface "Legacy" that needs half of its
methods deprecated
-Move the non-deprecated methods to a new "Modern" interface
-Legacy inherits from Modern
Existing clients can then use Legacy with no change.
New clients move to Modern, to make it clear that they don't want to
use legacy stuff.
Mark the whole Legacy interface as deprecated, recommend moving to
Modern
Existing services are explicitly registered as both Modern and Legacy.
No need to redesign things, just move them around.
WDYT?
+1, which would bring us to naming.. one suggestion would be
/** @deprecated */
public interface JobManager extends JobManager2 /* Modern */ {
..
}
Cheers,
Stefan
