reef-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julia Wang (QIUHE)" <>
Subject RE: REEF Services
Date Wed, 24 Feb 2016 23:32:59 GMT
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:



-----Original Message-----
From: Markus Weimer [] 
Sent: Wednesday, February 24, 2016 3:04 PM
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?


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