+1 for iteration towards better single responsibility design and more
easily-digestible classes.
Regarding method names, I think that there would be some good utility in
having "onGroup" methods, as well.
If we're not opposed to descriptive verbosity, I might prefer
"onServersHostingRegion" more than "onRegion".
On Wed, Mar 7, 2018 at 1:45 PM, Dan Smith <dsm...@pivotal.io> wrote:
> Hi Udo,
>
> +1 for making the function service not static and spitting it into client
> and server FunctionService objects!
>
> We do have Cache and ClientCache right now. So I would recommend this API
> rather than putting two methods on Cache. Cache is already the the server
> side API.
>
> Cache {
> ServerFunctionService getFunctionService()
> }
>
> ClientCache {
> ClientFunctionService getFunctionService()
> }
>
> If at some point we split the client side API into a separate jar the API
> shouldn't need to change. If you don't like ClientFunctionService, maybe
> o.a.g.cache.client.execute.FunctionService? We would never want two
> different versions of org.apache.geode.function.FunctionService. People
> wouldn't be able to test a client and server in the same JVM.
>
> Also, you might want to check out this (somewhat stalled) proposal -
> https://cwiki.apache.org/confluence/display/GEODE/
> Function+Service+Usability+Improvements. We had buy in on this on the dev
> list but have not found cycles to actually do it yet. But maybe now is the
> time?
>
> -Dan
>
> On Wed, Mar 7, 2018 at 11:18 AM, Udo Kohlmeyer <u...@apache.org> wrote:
>
> > Hi there Apache Dev's,
> >
> > Please look at the proposal to improve the FunctionService and remove the
> > static invocation of it from within the Cache.
> >
> > https://cwiki.apache.org/confluence/display/GEODE/Function+
> > Service+Refactor+-+Removal+of+static-ness+and+splitting+of+
> > client+and+server-side+FunctionService
> >
> > --Udo
> >
> >
>
