I guess the value of building other messages on top of the function service mostly comes into play when we start talking about smarter clients that can do single hop. At that point it's really nice to have have a layer that lets us send a message to a single primary, or all of the members that host a region etc. It is also nice that right now if I add new function that functionality becomes available to gfsh, REST, Java, and C++ developers automatically.
I do agree that the new protocol could build in these concepts, and doesn't necessarily have to use function execution to achieve the same results. But do at least consider whether new developers will want to add new functionality to the server via functions or via your this new protocol. If it's harder to use the new protocol than to write a new function and invoke it from the client, then I think we've done something wrong. A couple of other comments, now that I've looked a little more: 1) The list of error codes <https://cwiki.apache.org/confluence/display/GEODE/RegionAPI#RegionAPI-ErrorCodeDefinitions> seems really incomplete. It looks like we've picked a few of the possible exceptions geode could throw and assigned them integer ids? What is the rational for the exceptions that are included here vs. other exceptions? Also, not all messages would need to return these error codes. 2) The existing protocol has some functionality even for basic puts that is not represented here. Client generate an event id that is associated with the put and send that to the server. These event ids are used to guarantee that if a client does put (A, 0) followed by put (A, 1), the resulting value will always be 1, even if the client timed out and retried put (A, 0). The event id prevents the lingered put that timed out on the server from affecting the state. I'm not saying the new protocol has to support this sort of behavior, but you might want to consider whether the current protocol should specify anything about how events are retried. -Dan
