Okay .... but how do I has an implementer of a driver know what messages need an event id and which don't? It seems like maybe this belongs with those message types, rather than in a generic header. Or maybe you need to start organizing messages into classes - eg messages that change state and messages that don't and abstracting out commonality.
It's also not clear exactly what the event id should be set to. When do a change the sequence id? Does it have to be monotonically increasing? What should the uniqueId be? -Da On Wed, May 3, 2017 at 5:07 PM, Udo Kohlmeyer <ukohlme...@pivotal.io> wrote: > Correct, > > I did miss that. @Dan, if you look at https://cwiki.apache.org/confl > uence/display/GEODE/Message+Structure+and+Definition#Messa > geStructureandDefinition-MetaDataforRequests specifies how we provide > EventId information. > > > > On 5/3/17 09:53, Bruce Schuchardt wrote: > >> I believe Hitesh put EventId in the metadata section. >> >> Le 5/2/2017 à 2:22 PM, Udo Kohlmeyer a écrit : >> >>> 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/conf >>>> luence/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 >>>> >>> >>> >>> >> >
