Hi! > What you’ve described is how you would provide your own Promises > implementation (see also the Aries Promise > implementation: > https://github.com/apache/aries/tree/trunk/async/promise-api/src/main/java/org), > and could be what you choose to do. I would, however, consider > attempting to reuse the Aries implementation first (or even contributing > to it).
I had another look at the Aries implementation. It is interesting that you treat the chained promises differently than onResolve runnable callbacks (by not executing the chain is a separate executor). Do you expect the chain to be non-blocking, and onResolve runnable callbacks to be? I'll think about contributing a flag (or alternative implementation) that runs callbacks in the resolving thread. In general, I am also interested in minimizing the overhead associated with promises. Do you have any benchmarks to compare alternative implementations? > The Aries implementation is somewhat different from the default OSGi > implementation, as it also > provides org.apache.aries.async.promise.PromiseImpl as an exported type. > This gives you the ability to directly control which executor is going > to be used if you call new PromiseImpl(executor) instead of new > Deferred(). Note that you could do this inside your Execution Service > without requiring that anyone else use Aries Promises, it is simply an > implementation detail of the internals of your service. I can see myself replacing those calls to SomeService.deferred() that instantiate the right object (PromiseImpl) with the right setup (executor/scheduler/callback strategy). I'd rather avoid depending directly on Aries' PromiseImpl in case the API evolves in another direction. I am still not sure if it's worth it to pass an extra reference (and a service reference that might be stalled) to an object that should ideally be super cheap to instantiate for two methods that can be implemented externally, just for the sake of brevity :). > The model that OSGi tries to promote is one of maximum sharing within a > given set of constraints. It is therefore possible for lots of people to > use, and implement, promises simultaneously within the framework. The > important things are: > > * Anyone who wants to use *or* implement the API must import it > * Anyone who wants to provide the API must export it [snip] > I hope that makes sense - it can be a little brain-bending when you > first think about it! Your explanation totally makes sense and confirms I understood it right :). Thanks again for your answers! Simon _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
