reef-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Chung <afchun...@gmail.com>
Subject Re: REEF Services
Date Thu, 03 Mar 2016 22:22:26 GMT
Hi Shravan and Markus,

Sorry for being late to the discussion. Maybe I'm missing something,
but what happens when a user binds an object in a
`SharedContextInjector` but does not instantiate it until the user
pushes a child Context? In this case, it seems like if the first child
Context of the original Context is popped off and a second child
Context is pushed on that requires the object to be injected, the
object will not be shared across the two children Contexts. The
different resulting behavior is pretty subtle here.

Thanks,
Andrew

On Fri, Feb 26, 2016 at 10:31 AM, Shravan Matthur Narayanamurthy
<shravanmn@gmail.com> wrote:
> Hi Markus,
>
> I think you have captured our conversation very well. It makes perfect
> sense to me :)
> One thing, though, is whether we want to call the ContextConfiguration as
> LocalContextConfiguration or with some other prefix to make it explicit
> that it is not shared.
>
> @Julia: The notion of Service in REEF was to create a mechanism to share
> configuration and the associated state with all the descendants. I think
> creating objects separately was a certain nuance of the design that we feel
> is not necessary after building a couple of "Services". Since the term
> Service is confusing, we just want to get rid of it and use the Start &
> Stop Handlers for controlling the lifecycle of objects that are a part of
> your state which is shared with the descendants. As you rightly point out
> the handlers are tied to the Context's life-cycle. Since we want the state
> to be shared it makes sense to tie the scope and extent of that state
> to the lifetime of the contexts  they are a part of.
>
> As a part of this I think we should also create different Start/Stop
> handlers for both the local/shared contexts so that we give finer-grained
> control on the scope & lifetime of the state to the user.
>
> --Shravan
>
>
>
> On Thu, Feb 25, 2016 at 12:55 PM, Julia Wang (QIUHE) <
> Qiuhe.Wang@microsoft.com> wrote:
>
>> Make sense.
>>
>> The only thing is Context Handlers are more tight to ContextLlifeCycle.
>> They are designed (or at least from Name) for doing something when context
>> starts and stops. The services are just some objects which are instantiated
>> with Context objects.
>>
>> -----Original Message-----
>> From: Markus Weimer [mailto:markus@weimo.de]
>> Sent: Thursday, February 25, 2016 10:30 AM
>> To: dev@reef.apache.org
>> Subject: Re: REEF Services
>>
>> 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
>>

Mime
View raw message