Thanks - that’s a very clear explanation. Robert A. Decker [email protected] http://robdecker.com/about
On 16 Jun 2014, at 14:42, Dominik Süß <[email protected]> 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 >> >> >>
