>>he way I'm thinking of it, our our existing function execution code is a
lower level API on top of which an annotation based API can be constructed.
Does that seem reasonable?<<
Exactly.
>>Or do you think we should drop the RegionFunction/MemberFunction
interfaces entirely in favor of an annotat
I'd rather have it spelled out with getArguments / setArguments.
Thanks,
Barry Oglesby
GemFire Advanced Customer Engineering (ACE)
For immediate support please contact Pivotal Support at
http://support.pivotal.io/
On Thu, Dec 17, 2015 at 2:46 PM, Dan Smith wrote:
> Hi Barry,
>
> That seems rea
Hi Wes,
I really like what spring data gemfire has done. I like the fact that you
get to create a client side interface for the function as well as defining
the method on the server side as you've outlined.
One thing that's slightly different about that approach is that you no
longer have a Funct
Hi Barry,
That seems reasonable. What would you prefer - Args or Arguments?
-Dan
On Thu, Dec 17, 2015 at 9:32 AM, Barry Oglesby wrote:
> These look good. One small change I would like to see:
>
> Can you make these consistent (either withArguments or getArgs)
>
> Execution:
>
> public Executio
These proposals are great. I find convenient the signature matching that
Spring GemFire provides. How difficult would it be to create a late-binding
call to a matching signature based on the argument types for developer
convenience?
The following is from
http://docs.spring.io/spring-data-gemfire/d
These look good. One small change I would like to see:
Can you make these consistent (either withArguments or getArgs)
Execution:
public Execution withArgs(Object args);
FunctionContext:
public Object getArguments();
Barry Oglesby
GemFire Advanced Customer Engineering (ACE)
For immediate sup
The suggested changes are good.
Regards,
Rajiv Kumar
On Thu, Dec 17, 2015 at 7:55 PM, pulkit chandra
wrote:
> These changes look good.
>
> Might I suggest another improvement, since we are looking at the function
> code.
>
> Currently we execute the function code in the same thread as the reque
These changes look good.
Might I suggest another improvement, since we are looking at the function
code.
Currently we execute the function code in the same thread as the request
which has submitted the function to server. Customer have some times
reached out with issues where we see issues when t
Hi all,
Ashvin, Gester and I have gone over our function execution API, and we have
some proposals for how we should improve the function service API to make
it a little bit easier to use. Please take a look at the proposals on the
wiki and let us know what you think:
https://cwiki.apache.org/con
