I think the current proposal seems to be gloming some things together that probably belong in different layers.
The message header currently is specified to have things like correlation id, isPartial message, and also metdatadata about whether the key or the value is JSON. Fragmenting messages (isPartialMessage) seems like it belongs at a lower level, and depending on what transport your are using is probably already handled (TCP, HTTP). Potentially similar issue for request/response (correlationId) - if you were going over http that would already be handled. Whether a value is JSON seems like it belongs at a higher level that specifies the value serialization format. Not to mention not all messages have keys and values, and some have more than one. If wonder if it would make more sense to organize the message structure into layers that each have their own responsibility - a fragmentation layer (maybe not necessary), a request/response layer (maybe not necessary, not needed for all message types), function execution layer, individual operations layer (put, get), value serialization layer. Without having nailed down what underlying serialization framework you are using, talking about field byte sizes, etc. seems a bit premature. -Dan On Fri, Apr 28, 2017 at 2:49 PM, Udo Kohlmeyer <ukohlme...@pivotal.io> wrote: > Hi there Geode community, > > The new Client-Server protocol proposal is available for review. > > It can be viewed and commented on https://cwiki.apache.org/confl > uence/display/GEODE/New+Client+Server+Protocol > > --Udo > >
