Mailing-List: contact dev-help@reef.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@reef.apache.org
Subject: Re: REEF Services
To: dev@reef.apache.org
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>
 <CAB7WbuvxhfXv0+JLCv7xjrGnykufsJQkLWXDch9H7AAK1xuMKw@mail.gmail.com>
 <CAOFpRGDPB_Ar4v=7QumTAgWL40gWnLxo2Z_6q6v_pUhA0aHoog@mail.gmail.com>
From: Markus Weimer <markus@weimo.de>
Message-ID: <56CF4831.5010501@weimo.de>
Date: Thu, 25 Feb 2016 10:30:09 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
 <CAOFpRGDPB_Ar4v=7QumTAgWL40gWnLxo2Z_6q6v_pUhA0aHoog@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

Hi,

Shravan and I just had a bit of a brainstorm on this least clear concept
of the REEF API. Here is what we came up with as a proposal:

  (1) Remove the explicit notion of `Service` from the API. If an
      application wants to make sure objects are instantiated before
      the Tasks or other Contexts are spawned, those objects can be
      depended upon by the `ContextStart` handlers.

  (2) Rename `ServiceConfiguration` and `ServiceInjector` and related
      items to `SharedContextConfiguration` and
      `SharedContextInjector`. That way, their function is clear: Stuff
      in them will be inherited by Contexts spawned. Stuff in the
      `ContextConfiguration` and `ContextInjector` won't be. I use
      "stuff" here as an overloaded technical term: It denotes all the
      bindings inside a `Configuration` as well as all the already
      created instances in an `Injector.

Shravan, did I capture our conversation correctly?

Does this make sense to anybody but Shravan & me?

Markus