reef-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Weimer <>
Subject Re: REEF Services
Date Wed, 24 Feb 2016 23:40:08 GMT
If we do that, we'd loose the flexibility of stacking contexts. In the
current design, there is no difference between root and other
contexts, which is more general.


On Wed, Feb 24, 2016 at 3:32 PM, Julia Wang (QIUHE)
<> wrote:
> We can have handlers attached to RootContext level so that they can be inherited by all
the sub-contexts, and individual Context level handlers. How about:
> RootContextStart/StopHandler
> ContextStart/StopHandler
> Thanks,
> Julia
> -----Original Message-----
> From: Markus Weimer []
> Sent: Wednesday, February 24, 2016 3:04 PM
> To:
> Subject: Re: REEF Services
> Yes, that could work. Especially for .NET,where we don't have a legacy problem with that.
> However, we still need two configurations: One which is inherited by sub-contexts and
one which isn't. What would be good names for these?
> Markus
> On Wed, Feb 24, 2016 at 2:50 PM, Shravan Matthur Narayanamurthy <>
>> How about we abandon the Service notion and use the ContextStart/Stop
>> handlers for what we wanted to achieve with Services. If you want the
>> functionality of a Service, when you configure the Context add all the
>> configuration and also implement ContextStart/Stop handlers for
>> implementing lifecycle of the Service with the required objects
>> getting injected into the constructors of the Start handler. This is
>> actually what I see in all the implementations I see today.
>> --Shravan
>> On Tue, Feb 16, 2016 at 9:13 AM, Markus Weimer <> wrote:
>>> On 2016-02-12 11:40, Andrew Chung wrote:
>>>> My understanding is that they are just a set of injectable objects
>>>> that don't necessarily have anything in common.
>>> Correct. That name is misleading, not my finest hour in naming things
>>> :) As the introduction of Services pre-dates the Open Source release
>>> of REEF, let me add a bit of back story:
>>> Services are meant to be the extension hooks the API of the Driver
>>> and the Evaluators. Tang solves much of this, as one can just merge
>>> `Configuration` for additional libraries to the Driver / Evaluator
>>> `Configuration` and then depend on instances from those libraries.
>>> On the Driver, this is really all we need, as there is only one
>>> Driver and the life cycle of the Service completely matches the one of the Driver.
>>> On the Evaluator, the story got more tricky: The Evaluator's life
>>> cycle is decoupled from the Task life cycle. There is no guarantee
>>> that subsequent Tasks will need the same Services. Some Services may
>>> be detrimental to the performance of one Task, while required by another.
>>> Think of caching layers which occupy lots of memory as an example.
>>> Even worse, some Services are incompatible with one another (version hell).
>>> Hence, we can't bind Services to the Evaluator's life cycle.
>>> But we can't bind them to the Task life cycle either: There is no
>>> guarantee that subsequent Tasks on the same Evaluator do not need the
>>> same Services either. And important state might be lost if we cleared
>>> out the Services in between Tasks.
>>> Hence, we need a way to control the life cycle of these Services
>>> independently of the Evaluator and the Task: Contexts. Mind you,
>>> Services on the Evaluator are just what they are on the Driver:
>>> injectable instances.
>>> However, we now need to control the singleton property of these objects.
>>> Logically, a Service should be a singleton for the duration of a
>>> Context. In order to make that happen, we need to instantiate them
>>> before the Task gets instantiated. In order to do this, we need an
>>> enumeration of the classes considered part of the Service, hence the
>>> `ServiceConfiguration`: Its main purpose is to tell the Evaluator
>>> which objects it shall instantiate before the Task and hang onto in
>>> between tasks. That is the only thing distinguishing a Service from
>>> any other injectable object.
>>> Long story short: There is no need for them to all implement a common
>>> base interface. Or that need hasn't come up yet :)
>>> Markus

View raw message