reef-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Weimer <mar...@weimo.de>
Subject Re: REEF Services
Date Wed, 24 Feb 2016 23:04:22 GMT
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
<shravanmn@gmail.com> wrote:
> 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 <markus@weimo.de> 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
>>

Mime
View raw message