You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Oliver Lietz <ap...@oliverlietz.de> on 2014/07/10 09:48:43 UTC

Re: events vs jobs

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 <de...@robdecker.com>
> 
> 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
> > decker@robdecker.com
> > 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.


Re: events vs jobs

Posted by Carsten Ziegeler <cz...@apache.org>.
I'm right now doing some experimental stuff, removing all the deprecated
stuff to get the implementation simpler is one step.
And spltting the bundle into two makes sense as well.

Regards
Carsten


2014-07-10 9:48 GMT+02:00 Oliver Lietz <ap...@oliverlietz.de>:

> 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 <de...@robdecker.com>
> >
> > 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
> > > decker@robdecker.com
> > > 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.
>
>


-- 
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org