Thanks for your thoughts, Dan. Some additional info, taking your items # by #:
1) correlationID was put in with the thought that we could support out-of-order messages in a future version. You have any input on that plan? 2) Create/destroy region will be added after GA v1.0, so these messages should be removed before GA. 3) Idea has been that GetRegion would provide limited metadata on a region, similar to what the REST API does. Do see your point on "data policy" and "persistent" being redundant. 4) This could go either way -- we've gone with ease-of-use for clients, thinking it's not worth the added complexity for a potentially small over-the-wire savings. Would be interested in a good/strong argument for the other approach. Finally, we'll be working on a "how to implement a client" document soon, including the details you mention. We'd also like to have a simple client implemented in Go to go along with the "how-to". -Brian On Thu, Sep 21, 2017 at 10:48 AM, Dan Smith <dsm...@pivotal.io> wrote: > I'm curious about few things I see in the .proto files. > > 1) I see there is a correlationId in the MessageHeader definition. What is > that used for? I remember we had a discussion a while back where I thought > we had decided that might not be not necessary? > > 2) I also see a CreateRegionRequest and DestroyRegionRequest in the .proto > files. Are those actually going to be part of the 1.0 GA? Should these be > removed? > > 3) The GetRegion command seems like it is returning either too much > information or to little. It returns some of the attributes of the region, > like data policy, scope, whether it's persistent (duplicate of data > policy?). What is this command for, and should it really be returning this > information which seems irrelevant to the client? > > 4) For GetAll, PutAll, the old client server protocol did not return the > keys in the response, it just sent back the results in the same order as > the request. This saves some data on the wire. I"m not sure if it's worth > complexity for this new protocol or not. > > Looking forward to seeing some more information about how to actually use > these messages to communicate with a server - IE what type of connection > should I create, how SSL works, how authentication works, etc. > > -Dan > > On Fri, Sep 15, 2017 at 5:50 PM, Brian Baynes <bbay...@pivotal.io> wrote: > > > You can find them in the code, but we'll be providing better > documentation > > on the messages shortly. The proto files have the message definitions and > > they're pretty straightforward, but we'll have a more user-friendly > > write-up soon. > > > > > > On Sep 15, 2017 5:27 PM, "Dan Smith" <dsm...@pivotal.io> wrote: > > > > What's the best place to look for more details on the specific protocol > for > > the v1.0 messages? The other pages on https://cwiki.apache.org/ > > confluence/display/GEODE/New+Client+Server+Protocol? Or directly in the > > code somewhere? > > > > -Dan > > > > On Fri, Sep 15, 2017 at 11:15 AM, Brian Baynes <bbay...@pivotal.io> > wrote: > > > > > Greetings, friends of Geode. > > > > > > Work has been progressing on the new client/server protocol for Geode > and > > > we're approaching a GA v1.0. Completed work/features include put/get, > > > putAll, getAll, remove, one-way SSL, authentication and authorization, > > and > > > support for primitive types and JSON documents as values (saved in PDX > on > > > the server). > > > > > > Invite you to review the road map toward GA v1.0, the features proposed > > for > > > post-v1.0, and give us your feedback! (Directly in Confluence or here > on > > > dev@geode.apache.org) > > > > > > New Client/Server Protocol - Road Map, Proposed > > > <https://cwiki.apache.org/confluence/display/GEODE/Road+ > Map%2C+Proposed> > > > > > > > > > Thanks for your input, > > > > > > Brian > > > > > >
