Hi,
On 09.07.20, 10:13, "Julian Sedding" wrote:
> I don't have a use case, but could imagine that introspection of the
> state could be useful for reporting (e.g. a web-console report of all
> active toggles and their state). I understand the desire to keep an API
> minimal, but on the other
Hi Marcel
On Tue, Jul 7, 2020 at 12:02 PM Marcel Reutegger
wrote:
>
> Hi,
>
> Thanks for the feedback Julian.
>
> On 07.07.20, 10:45, "Julian Sedding" wrote:
> > I'm not sure about the aspect of the implementation, that FeatureToggle
> > is Closeable and probably often short-lived. Given that
Hi,
I wanted to keep dependencies to a minimum and provide flexibility
how features are actually toggled. The proposal only depends on the
already existing Oak concept of a Whiteboard. In most cases this
indeed means a feature toggle is registered as an OSGi service.
Regards
Marcel
On
Hi,
Thanks for the feedback Julian.
On 07.07.20, 10:45, "Julian Sedding" wrote:
> I'm not sure about the aspect of the implementation, that FeatureToggle
> is Closeable and probably often short-lived. Given that the
> FeatureToggleAdapter is registered with the whiteboard, and thus likely
>
Hey Marcel,
As I also mentioned in the JIRA ticket. What is the reasoning to put this in
Oak code, and not directly in Felix? I see no clear connection with Oak and you
even use a lot of OSGi concepts
Greets,
Roy
> On 7 Jul 2020, at 10:45, Julian Sedding wrote:
>
> Hi Marcel,
>
> I think
Hi Marcel,
I think the API is elegant. Short of running "feature" code in a
closure, a "try with resource" block encourages developers to clearly
delimit the block of code that is subject to the feature toggle,
hopefully resulting in readable code.
I'm not sure about the aspect of the
Hi,
There is a proposal ready in OAK-9132 [0] that introduces the concept of
feature toggles [1]. A FeatureToggle is basically a boolean value that
controls whether some new feature is available. The implementation uses
the Oak Whiteboard to register a feature toggle. It is then up to
another