On Monday 16 June 2014 14:42:17 Dominik Süß wrote: > Hi Robert, > > Jobs are Events guaranteed to be processed. Therefore jobs are an extension > of the event engine that takes care of persisting the eventinformation and > predefines various attributes. The Job API is convenient way to create and > consume jobs without the need to manually compose those events which was > much more complicated in first place. > > In short you do not need to migrate your old jobs - the old way of creating > those still works, but for new job requirements you may want to use the new > API for the sake of simplicity of code. > > The event API itself will anyways still play an important role because it > is light weight and it is an easy way to losely wire logic together. > > The stability of jobs always come at a price (de/serializing data to > persistence), so you might want to think twice if you really require > guarrantee of processing or if losing the event on restart is acceptable. > > HTH > Dominik > > > > > On Mon, Jun 16, 2014 at 1:20 PM, Robert A. Decker <[email protected]> > > wrote: > > We have the new jobs system (JobConsumer, jobManager, etc). But we also > > still use osgi’s events to, for example, handle > > SlingConstants.TOPIC_RESOURCE_ADDED. > > > > Should we be thinking about jobs and events as separate behaviors? Should > > we be using the old event system to announce events and then using the > > new job system to do work? Is that a good strategy? Or does it not > > really matter, and we should use the new jobs system for everything? > > > > Robert A. Decker > > [email protected] > > http://robdecker.com/about
hi, as Carsten is working on removing deprecated stuff from the event bundle wouldn't it make sense to split the bundle into dedicated event and job bundles? Regards, O.
