ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Kozlov <skoz...@gridgain.com>
Subject Re: Thin Client Protocol documentation
Date Wed, 29 Nov 2017 11:30:35 GMT
Pavel

Could you update the page by following:

 - String, date, UUID arrays allow to put NULL. Due to that every item in
the array written as type code byte (default item type or null type code) +
type data. It should be detailed explained (looks like that the table
should have an addtional column called for instance "nullable")

-  UUID type takes 16 bytes length

thanks


On Mon, Nov 27, 2017 at 4:37 PM, Sergey Kozlov <skozlov@gridgain.com> wrote:

> Pavel
>
> Thanks for explanations!
>
> On Mon, Nov 27, 2017 at 2:46 PM, Pavel Tupitsyn <ptupitsyn@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 <skozlov@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 <pgarg@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 <ptupitsyn@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
>



-- 
Sergey Kozlov
GridGain Systems
www.gridgain.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message