Mailing-List: contact dev-help@reef.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@reef.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <DM2PR03MB319D23D399DE9AD0BF9E1AC90A50@DM2PR03MB319.namprd03.prod.outlook.com>
References: 
 <CAHzzxZRzdz109gNhWS80dgcFjYx9dtks8OTQe8jfhELE_z4HGw@mail.gmail.com>
 <CADq0cj6A2pdyQ9F=rZ4Y3UdDH1J7HpuXxJUM8_aJaGmES6RDvw@mail.gmail.com>
 <CAHzzxZQkB4FosZ-9QWaJgTHmNfLNNMNm5vYijY7hOe-E8ins7g@mail.gmail.com>
 <DM2PR03MB3196196BC6197B14F54D89690DF0@DM2PR03MB319.namprd03.prod.outlook.com>
 <56B0F0BB.9090503@weimo.de>
 <DM2PR03MB31982955DDA32E507000D9490DF0@DM2PR03MB319.namprd03.prod.outlook.com>
 <CAHzzxZRSOCVnctReA14L1Fs7sbF3xT9HgogqXiAMQCfSYRcF4Q@mail.gmail.com>
 <DM2PR03MB319DEC83903CDB48CFCCDD990A90@DM2PR03MB319.namprd03.prod.outlook.com>
 <CAHzzxZSqwpPs3OW-9-MyK_A7zpiK2vQ5mGgFRO7uDT_NM_B3tw@mail.gmail.com>
 <56C358B0.1040001@weimo.de>
 <CAB7WbutUoAfqgJdQuD3QsXDnVG4QJBWaN5Wq_kJ5GMe74xuD-Q@mail.gmail.com>
 <CAOFpRGB6PmZZo2H_bcNvuy1u29+uyhmTkuS9GEQ+JYigB-unMg@mail.gmail.com>
 <DM2PR03MB319D23D399DE9AD0BF9E1AC90A50@DM2PR03MB319.namprd03.prod.outlook.com>
From: Markus Weimer <markus@weimo.de>
Date: Wed, 24 Feb 2016 15:40:08 -0800
Message-ID: 
 <CAOFpRGCyhVWhzTb2a7XrsxHAKy-N3Tnc00TyUqZeNTV2NdpAbg@mail.gmail.com>
Subject: Re: REEF Services
To: dev@reef.apache.org
Content-Type: text/plain; charset=UTF-8

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.

Markus

On Wed, Feb 24, 2016 at 3:32 PM, Julia Wang (QIUHE)
<Qiuhe.Wang@microsoft.com> 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 [mailto:markus@weimo.de]
> Sent: Wednesday, February 24, 2016 3:04 PM
> To: dev@reef.apache.org
> 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 <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
>>>