Hey Timothy, Thanks for your answer! Final(?) comments inside :-)
> It sounds as though you’re making pretty heavy use of Promises, which is > great to hear! I agree that an external method can be used to provide > timeouts, but the fact that users (including me) have felt it necessary > to create the method indicates that it should probably be part of the > core API. In general we have tried to keep the Promise > well-encapsulated, so adding timeout to the Promise interface felt most > consistent. Well, I can certainly understand your point of view, and I'm grateful that you explained how you came to that solution. As the ad said, "APIs are forever", and there's also this quote from Ben Franklin obviously referring to API design that comes to mind: "Those who sacrifice purity for practicality deserve neither" ;) Jokes aside, a *big* selling point from the Promises API was the fluent/monadic writing style, especially over Guava's futures that are clumsy to code with in comparison. The fluent side of the Promises API is a big enabler and allows us to write non-blocking code almost transparently, so I understand why it is appealing to go that route for timeouting, which is also very much necessary. I just wonder if there would not be a way to get the better of both worlds, for instance by keeping Promises as is with respect to threading (e.g, the new callback is not a problem), but having the timeout/delay facilities in a subtype, with its own deferred variant that takes a scheduler. > At the moment the behaviour of the OSGi-provided implementation works > well for you, as it creates no threads at all, however as of Promises > 1.1 this is likely to no longer be the case. This leaves you with a > decision point: > > * Stick with Promises 1.0 - if the new functionality is not needed in > your system then it is not mandatory to upgrade. > * Use/Embed a specific implementation that gives you sufficient > control of the threading. If you couple to a specific implementation > (e.g. Apache Aries) then you can supply the Executor/Scheduler when > you instantiate the Promise > * Write your own promise implementation to get the finest possible > control of the Promise lifecycle > * Upgrade to the standard Promises 1.1, accepting that there will be > some threads created Yep, I have to think it through. Back when I chose to go for OSGi Promises, I was ready to roll my own implementation/API but I found that it suited me. I wrote this mail today because I thought it was not too late for that feedback, thinking that if I have these requirements, others are bound to have the same eventually, especially as people are moving to non-blocking, message-based architectures, and try to optimize resource utilization. > As someone also uses Promises quite a lot in infrastructure services, I > can wholeheartedly recommend embedding a specific implementation if it > gives you the control that you need. OSGi is very good at handling > “substitutable” packages, i.e. providers that also import the API. An > example would be the Aries Async Service implementation - the Async > Service repackages the Aries Promise implementation, but imports the > Promise API. This means that whichever way round bundles resolve they > share the API packages, but it still allows Aries Async to use the Aries > Promise implementation, avoiding excessive thread creation. This is the > mechanism by which Felix SCR can use promises and co-exist in the same > runtime as another promises provider. Do you mean rolling my own API that implements OSGi's Promise interface for compatibility, but exclusively using my variants of Deferred/Promises#resolved/Promises#failed to ensure I instantiate my own PromiseImpl? Thanks again, Simon _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
