Hi everyone, Just a reminder that initial spec is on wiki: https://cwiki.apache.org/confluence/display/IGNITE/IEP-9+Thin+Client+Protocol
It is quite terse and may be harder to understand. Prachi tried to document all of this in a more user-friendly manner with examples and so on. On Fri, Jan 19, 2018 at 6:30 AM, Denis Magda <dma...@apache.org> wrote: > Lucas, thanks for chiming in, > > The protocol itself consists of all these magic constants (type and > operations codes). See type codes table from this section: > https://apacheignite.readme.io/docs/binary-client- > protocol#section-data-objects <https://apacheignite.readme. > io/docs/binary-client-protocol> > > Hope that my explanation given to Alexey makes sense to both of you. > > Initially, we didn’t plan to have the code snippets at all and wanted to > document the protocol in a way similar to Mongo’s protocol: > https://docs.mongodb.com/manual/reference/mongodb-wire-protocol/ < > https://docs.mongodb.com/manual/reference/mongodb-wire-protocol/> > > But after several iterations we agreed to simplify a life of those who > will be developing thin clients on top of the protocol and filled out the > doc with as many code snippets as possible. Again, the snippets are not a > complete application and this is why we ignored some of the best practices > used by Java developers. > > — > Denis > > > On Jan 18, 2018, at 7:11 PM, Lucas Beeler <lucas.bee...@gridgain.com> > wrote: > > > > Hi Igniters, > > > > I’m with Alexey here: hard-coded “magic” literals make code hard to read > and neither communicate coding professionalism nor comport with published > Sun/Oracle style guides. So I suggest that: > > For already defined symbolic constants, let’s use them instead of > literal values > > If there are literal values for which symbolic constants haven’t yet > been defined, let’s define symbolic constants for them, commit this change > to master, and start using the newly defined symbolic constants > > Anyhoo, that’s just my two cents. > > > > As always, it’s a pleasure to be a part of Ignite development... > > > > Cheers guys & gals, > > Lucas > > > > -- > > Lucas BEELER > > Technical Consultant, Professional Services > > GridGain Systems > > www.gridgain.com <http://www.gridgain.com/> > > > >> On Jan 18, 2018, at 6:47 PM, Alexey Kuznetsov <akuznet...@apache.org > <mailto:akuznet...@apache.org>> wrote: > >> > >> Prachi, Denis, > >> > >> > >> It is OK that we are using numbers in code samples instead of named > >> constants? > >> > >> For example: > >> writeByteLittleEndian(3, out); // Integer type code > >> > >> It could be smth. like this: > >> writeByteLittleEndian(TYPE_INT, out); // Integer type code > >> > >> Where TYPE_INT is declared at some place: > >> .... > >> public static final int TYPE_INT = 3; > >> .... > >> > >> Make sense? > >> > >> > >> On Fri, Jan 19, 2018 at 4:47 AM, Prachi Garg <pg...@gridgain.com > <mailto:pg...@gridgain.com>> wrote: > >> > >>> Igniters, > >>> > >>> The document for Binary Client Protocol (awaiting 2.4 release) is > ready on > >>> Apache Ignite readme.io <http://readme.io/>. This document explains: > >>> > >>> - How to connect to Ignite cluster > >>> - Common message format (Request/Response header) > >>> - Supported Data types and their format > >>> - Request/Response format for each message type > >>> > >>> Here are the links - > >>> > >>> https://apacheignite.readme.io/docs/binary-client-protocol < > https://apacheignite.readme.io/docs/binary-client-protocol> > >>> > >>> https://apacheignite.readme.io/docs/binary-client-protocol- > >>> key-value-operations > >>> > >>> https://apacheignite.readme.io/docs/binary-client- > protocol-sql-operations > >>> > >>> https://apacheignite.readme.io/docs/binary-client-protocol- > >>> binary-type-operations > >>> > >>> https://apacheignite.readme.io/docs/binary-client-protocol- > >>> cache-configuration-operations > >>> > >>> > >>> Currently these pages are hidden and are accessible only with the link. > >>> They will be active after the release. > >>> > >>> -Prachi > >>> > >> > >> > >> > >> -- > >> Alexey Kuznetsov > > > >
