Hi, This thread reminds me that Ian built Sling Jobs module [0]. IIUC from reading the project readme, Sling Jobs design focused on supporting the APIs from the Sling Events module that can be implemented efficiently on a messaging system.
I am thinking that the Sling Jobs API could help defining the Sling Events API to be deprecated or could serve as a new API (inline with Robert suggestion). Cheers, Timothee [0] https://github.com/apache/sling-org-apache-sling-jobs#apache-sling-jobs-support Le lun. 29 oct. 2018 à 16:53, Robert Munteanu <[email protected]> a écrit : > Hi Stefan, > > On Mon, 2018-10-29 at 14:47 +0100, Stefan Egli wrote: > > 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. > > > How about depreacting the JobManager completely and creating new API > which does exactly what we want? > > We can switch the JobManagerImpl to being a component registered only > if a certain configuration property is set. We can set the default to > 'false' and log a WARN when we register that component to make it clear > that it's not going to be supported. Eventually we can stop registering > the implementation outright and make the inconvenient methods throw an > UnsupportedOperationException. But I would prefer to create a new API > for new 'realities'. > > I know the transition will be more inconvenient, but a new API will > also force clients to make conscious choices about what they want to > support and a clear transition path. > > While not giving it a lot of thought to the names and the API methods > we could support, here's a strawman API we can bash: > > ---------------- > > // do we need both submit and create? > interface JobManager2 { > SubmittedJob submitJob(...) > JobBuilder createJob(...) > } > > // do we need both stop and remove? > interface SubmittedJob { > void retryJob() > void removeJob() > void stopJob() > } > > interface JobStatisticsManager { > getQueue(...); > getQueues(); > getStatistics(); > // etc, etc > } > > ---------------- > > The separation of concerns makes it quite clear what is possible and > what not, and additionally the client is required to hold on to the > SubmittedJob if they want to do anything more with it. > > We also might want to use exceptions instead of returning null in the > API, might make things clearer. > > Thoughts? > > Robert > > > > > > > > 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 > > >
