On Mon, 2018-10-29 at 17:42 +0100, Stefan Egli wrote: > Right, Sling Jobs can help in defining the deprecation, which is > exactly > what I've use it for now. (btw: I went even further in restricting > the > API, as I think retryJobById and getJobById are potentially expensive > as > well, thus lean towards deprecating those too - not sure about > getScheduledJobs...).
Those don't have to be expensive if you hold the state 'client-side' with the SubmittedJob object, then you simply submit the same data. (I may miss some specific knowledge of how eventing works though). > > Re new vs deprecation: I'd say if we would see need for changing the > actual API, ie the signatures, other than plain deprecating it, that > would be an argument for a new API. So I see that as the key > question. > As if we just deprecate, there are of course several advantages: > those > that don't violate anything can keep their code unchanged - the > implementation remains the same for now - no need to implement > additional, probably slightly different API... - no flags needed.. Yes, the discussion of deprecating vs adding new API is ... interesting :-) My personal opinion is that an interface with half of its methods deprecated is confusing and should not be used. But again, that is something up for discussion and just a personal opinion. Additonally,if the end-goal is to eventually replace it with a well- known external API then there is no point in investing in yet another API that is going to be replaced in a couple of years. Thanks, Robert
