reef-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shravan Matthur Narayanamurthy <>
Subject Re: REEF Services
Date Fri, 26 Feb 2016 18:31:28 GMT
Hi Markus,

I think you have captured our conversation very well. It makes perfect
sense to me :)
One thing, though, is whether we want to call the ContextConfiguration as
LocalContextConfiguration or with some other prefix to make it explicit
that it is not shared.

@Julia: The notion of Service in REEF was to create a mechanism to share
configuration and the associated state with all the descendants. I think
creating objects separately was a certain nuance of the design that we feel
is not necessary after building a couple of "Services". Since the term
Service is confusing, we just want to get rid of it and use the Start &
Stop Handlers for controlling the lifecycle of objects that are a part of
your state which is shared with the descendants. As you rightly point out
the handlers are tied to the Context's life-cycle. Since we want the state
to be shared it makes sense to tie the scope and extent of that state
to the lifetime of the contexts  they are a part of.

As a part of this I think we should also create different Start/Stop
handlers for both the local/shared contexts so that we give finer-grained
control on the scope & lifetime of the state to the user.


On Thu, Feb 25, 2016 at 12:55 PM, Julia Wang (QIUHE) <> wrote:

> Make sense.
> The only thing is Context Handlers are more tight to ContextLlifeCycle.
> They are designed (or at least from Name) for doing something when context
> starts and stops. The services are just some objects which are instantiated
> with Context objects.
> -----Original Message-----
> From: Markus Weimer []
> Sent: Thursday, February 25, 2016 10:30 AM
> To:
> Subject: Re: REEF Services
> Hi,
> Shravan and I just had a bit of a brainstorm on this least clear concept
> of the REEF API. Here is what we came up with as a proposal:
>   (1) Remove the explicit notion of `Service` from the API. If an
>       application wants to make sure objects are instantiated before
>       the Tasks or other Contexts are spawned, those objects can be
>       depended upon by the `ContextStart` handlers.
>   (2) Rename `ServiceConfiguration` and `ServiceInjector` and related
>       items to `SharedContextConfiguration` and
>       `SharedContextInjector`. That way, their function is clear: Stuff
>       in them will be inherited by Contexts spawned. Stuff in the
>       `ContextConfiguration` and `ContextInjector` won't be. I use
>       "stuff" here as an overloaded technical term: It denotes all the
>       bindings inside a `Configuration` as well as all the already
>       created instances in an `Injector.
> Shravan, did I capture our conversation correctly?
> Does this make sense to anybody but Shravan & me?
> Markus

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message