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: 
 <CAOFpRGB6PmZZo2H_bcNvuy1u29+uyhmTkuS9GEQ+JYigB-unMg@mail.gmail.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>
Date: Wed, 24 Feb 2016 16:10:00 -0800
Message-ID: 
 <CAB7WbuvxhfXv0+JLCv7xjrGnykufsJQkLWXDch9H7AAK1xuMKw@mail.gmail.com>
Subject: Re: REEF Services
From: Shravan Matthur Narayanamurthy <shravanmn@gmail.com>
To: dev@reef.apache.org
Content-Type: multipart/alternative; boundary=001a114b0beceb3f52052c8d00f8

--001a114b0beceb3f52052c8d00f8
Content-Type: text/plain; charset=UTF-8

Why do we need this distinction? Can we not have only inherited? It will
only be extra references anyway right? If there is some state in the your
hierarchy that is not shared, it is not possible to get rid of the storage
for that anyways.
--Shravan

On Wed, Feb 24, 2016 at 3:04 PM, Markus Weimer <markus@weimo.de> wrote:

> 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
> >>
>

--001a114b0beceb3f52052c8d00f8--