We are considering the function service, but again, this should not
detract from the proposed message specification proposal.
You are also correct in your observation of list of error codes not
being complete nor exhaustive. Maybe the first page needs to highlight
that this is a proposal and does not contain all the error codes that we
could per api.
As for the EventId, we will look into this and update the document
accordingly.
--Udo
On 5/2/17 13:42, Dan Smith wrote:
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
