ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Prachi Garg <pg...@gridgain.com>
Subject Re: Thin Client Protocol documentation
Date Wed, 29 Nov 2017 16:10:45 GMT
Hi Pavel,

In the operation request, what does the 'flags' parameter mean?


Thanks,
-Prachi

On Wed, Nov 29, 2017 at 5:27 AM, Pavel Tupitsyn <ptupitsyn@apache.org>
wrote:

> Sergey, good point, done.
>
> On Wed, Nov 29, 2017 at 2:30 PM, Sergey Kozlov <skozlov@gridgain.com>
> wrote:
>
> > 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