Am 19.10.15 um 15:57 schrieb Stefan Egli: > Hi, > > I think it could be useful to have a broader overview of use cases and > have them categorised. What comes to mind besides the cache-invalidation > case you mentioned (which I think is still a good candidate for external > observation events) is: > > * exactly once : eg when uploading an asset you want a certain job to be > started exactly once. Currently this uses internal events only (so kind > of not related to this external event topic) but it has the risk of > failing when the instance crashes before the job was created. Perhaps > we could add some framework support for this (auto-creation of a job?)
Uh, you're opening another can of worms :) But I see your point, now the only thing that really works is creating the job within the save operation of the asset. Everything that happens after the save can already be too late. This would basically mean: we send out observation events before the save and allow additional operations. We could handle this from within the resource resolver implementation. > > * maybe there's also at-least-once, not sure, but it might also be > solved with auto-spawning a job (perhaps less costly than exactly-once) I think this is more on the processing side of jobs, not really observation. > > If we're comfortable having covered all use cases we can probably disable > external observation event support entirely - but until then, even > switching > the default to be internal-only would probably reduce external events a > lot. With the new observation api we have the marker interface, so basically we know which events need to be sent across the wire. But still, it would be great if we can avoid this completely. Even for the caching use case. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland [email protected]
