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 <[email protected]> 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
