Pavel Thanks for the document and your efforts for new protocol. It was really helpful for playing around the python thin client design.
Could you explain some things that were still not clear for binary object format: 1. What a reason to introduce separated type codes for arrays? Why just we can't use the following? *<1 byte universal array code>* *<1 byte primitive code>* *<4 bytes length>* *<N bytes data>* We get 1 byte overhead but save 10 bytes in the code table. For arrays the overhead is really insignificant:10 longs array takes now 1+4+4*10=45 bytes vs 1+1+4+4*10=46 bytes for the approach Moreover for that appoach a new primitive code will be available for using for array immediately. 2. Why the arrays force to use a selected type? For python there's no limitations to use different types across one array (list). Would be good to introduce a new type that will allow that. It could be look like following *<1 byte universal array code>* *<1 byte no common type code*> <-- this says that every item must provide its date type code like it does regular primitive data *<4 bytes length>* *<1 byte item 0 type code>* <-- item provides its code *<N byte item 0 data>* <-- item provides its data *<1 byte item 1 type code>* *<N byte item 1 data>* etc Also that allow to put nested arrays without changes in type code table! For instance if we want to store 9 longs and 1 boolean it will take now 1+1+4+(1+9)*4+(1+1)=48 bytes (vs 45 bytes to store as 10 longs as usual). 3. Ther's only one way to store a dictionary (key-value) structure as value in the cache via Complex Object. But it looks like overcomplicated. I suppose to introduce a code for that *<1 byte key-value dictionary code>* *<4 bytes length>* *<1 byte key 1 **name **type code>* *<N byte key 1 name data>* *<1 byte value 1 type code>* *<N byte value 1 value>* *<1 byte key 2 **name **type code>* *<N byte key 2 name data>* *<1 byte value 2 type code>* *<N byte value 2 value>* etc Also that allow to put nested dictionaries without changes in type code table! Of course for the appoach above we get significat overhead for key storing. But I think it is acceptable for some cases and definitely ok for Python On Wed, Nov 22, 2017 at 9:14 PM, Prachi Garg <pg...@gridgain.com> wrote: > Thanks Pavel! The document has good information. I'll create one on > readme.io; will also add some examples there. > > On Wed, Nov 22, 2017 at 5:03 AM, Pavel Tupitsyn <ptupit...@apache.org> > wrote: > > > Igniters, > > > > I've put together a detailed description of our Thin Client protocol > > in form of IEP on wiki: > > https://cwiki.apache.org/confluence/display/IGNITE/IEP- > > 9+Thin+Client+Protocol > > > > > > To clarify: > > - Protocol implementation is in master (see ClientMessageParser class) > > - Protocol has not been released yet, so we are free to change anything > > - Protocol is only used by .NET Thin Client for now, but is supposed to > be > > used from other languages by third party contributors > > - More operations will be added in future, this is a first set of them, > > cache-related > > > > > > Please review the document and let me know your thoughts. > > Is there anything missing or wrong? > > > > We should make sure that the foundation is solid and extensible. > > > > > > Thanks, > > Pavel > > > -- Sergey Kozlov GridGain Systems www.gridgain.com
