Pavel Thanks for explanations!
On Mon, Nov 27, 2017 at 2:46 PM, Pavel Tupitsyn <ptupit...@apache.org> wrote: > Sergey, > > 1. Code table size does not affect anything, as I understand, so there is > no reason to introduce an extra byte. > 2. We have object arrays (code 23), I forgot to mention them, fixed. > 3. Also forgot, see code 25 in the updated document. > > Also note that operation codes have been updated (grouped by purpose) as > part of https://issues.apache.org/jira/browse/IGNITE-6989. > > Thanks, > Pavel > > On Sun, Nov 26, 2017 at 9:54 PM, Sergey Kozlov <skoz...@gridgain.com> > wrote: > > > 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 > > > -- Sergey Kozlov GridGain Systems www.gridgain.com
