You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@ignite.apache.org by Dmitriy Govorukhin <dm...@gmail.com> on 2018/05/14 15:58:05 UTC

supporting different configuration format json,yaml...

Hi, Igniters!

As far as I know, many people work on a thin client for different language
(go,js,php...).
Are there any reasons why ignite does not support yaml or json format for
configuration? or some other popular format?
In future, it can help to integrate with thin clients, for example, js
client may want to dynamic cache start, he passes cache configuration (in
native format, for js it will json) through TCP, Ignite node unwrap and
remap to java representation and dynamic start cache.

Re: supporting different configuration format json,yaml...

Posted by Igor Sapego <is...@apache.org>.

Dmitriy,

I guess, you can find some reasons in this discussion :)

Best Regards,
Igor

On Wed, May 16, 2018 at 11:18 AM, Dmitriy Govorukhin <
dmitriy.govorukhin@gmail.com> wrote:

> Folks,
>
> Why do you interpret the question as a necessity for action?
> In my first message, "Are there any reasons why ignite does not support
> yaml or json format for configuration? or some other popular format?"
>
> On Wed, May 16, 2018 at 10:35 AM, Dmitriy Setrakyan <dsetrakyan@apache.org
> >
> wrote:
>
> > I generally agree with Andrey Gura. I do not think that the effort
> required
> > to implement another format for configuration justifies the means. Let's
> > stick to the Spring configuration.
> >
> > D.
> >
> > On Wed, May 16, 2018 at 10:10 AM, Pavel Tupitsyn <pt...@apache.org>
> > wrote:
> >
> > > Andrey G, +1
> > >
> > >
> > > Andrey K,
> > >
> > > > json-schema
> > > It's a draft. XML schema is a mature standard.
> > >
> > > > eye fatigue
> > > Here is Ignite.NET config:  <cacheConfiguration cacheMode='Replicated'
> > > name='myCache'   />
> > > Equivalent JSON excerpt:  "cacheConfiguration": { "cacheMode":
> > > "Replicated", "name": "myCache" }
> > > Enough said I guess :)
> > >
> > >
> > >
> > > On Wed, May 16, 2018 at 12:48 AM, Andrey Gura <ag...@apache.org>
> wrote:
> > >
> > > > Guys,
> > > >
> > > > Spring is IoC and you can't offer any format that can  replace
> Spring.
> > It
> > > > will just limited DSL.
> > > >
> > > > Once again. We have enough problems with main functionality. Why do
> you
> > > > want to focus on minor features?
> > > >
> > > >
> > > > вт, 15 мая 2018 г., 23:26 Andrey Kuznetsov <st...@gmail.com>:
> > > >
> > > > > Pavel,
> > > > >
> > > > > One can use json-schema if necessary. Of course, XML is more
> powerful
> > > in
> > > > > many aspects, but produces more eye fatigue for humans. Of course,
> we
> > > are
> > > > > to stay with XML if switching to another configuration format
> > requires
> > > > > significant effort.
> > > > >
> > > > > BTW, first time I heard about JSON from [1] : " JSON is like XML,
> > > except
> > > > it
> > > > > doesn't suck ".
> > > > >
> > > > > [1] https://github.com/cajun-jsonapi/cajun-jsonapi/blob/
> > > > master/Readme.txt
> > > > >
> > > > >
> > > > > 2018-05-15 22:43 GMT+03:00 Pavel Tupitsyn <pt...@apache.org>:
> > > > >
> > > > > > JSON sucks for config files anyway, there are no comments, no
> > > schemas,
> > > > > > quotes are required around keys, etc
> > > > > >
> > > > > > Just answer one question: what issue are we trying to solve?
> > > > > > XML is not a problem IMO, complexity of our config is.
> > > > > >
> > > > > > On Tue, May 15, 2018 at 8:00 PM, Igor Sapego <isapego@apache.org
> >
> > > > wrote:
> > > > > >
> > > > > > > How are you going to translate this YAML config to Spring
> config?
> > > > > > >
> > > > > > > How would you deal with something like [1]?
> > > > > > >
> > > > > > > [1] -
> > > > > > > https://github.com/apache/ignite/blob/master/modules/
> > > > > > > platforms/cpp/odbc-test/config/queries-ssl-32.xml
> > > > > > >
> > > > > > > Best Regards,
> > > > > > > Igor
> > > > > > >
> > > > > > > On Tue, May 15, 2018 at 7:10 PM, Pavel Kovalenko <
> > > jokserfn@gmail.com
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Igor,
> > > > > > > >
> > > > > > > > Just get one of the config samples and translate it directly
> to
> > > > YAML:
> > > > > > > > XML - https://pastebin.com/wtQXXq8f
> > > > > > > > YAML - https://pastebin.com/akGu3e81
> > > > > > > >
> > > > > > > > 2018-05-15 18:49 GMT+03:00 Igor Sapego <is...@apache.org>:
> > > > > > > >
> > > > > > > > > Guys, if you think the YAML or JSON would be better, how
> > about
> > > > > > > > > you provide us a brief example of how such configs are
> going
> > to
> > > > > > > > > look, so we can compare and see, if this ever have any
> sense.
> > > > > > > > >
> > > > > > > > > Best Regards,
> > > > > > > > > Igor
> > > > > > > > >
> > > > > > > > > On Tue, May 15, 2018 at 4:20 PM, Ilya Kasnacheev <
> > > > > > > > > ilya.kasnacheev@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hello!
> > > > > > > > > >
> > > > > > > > > > Maybe we should take .Net configuration as a standard,
> > extend
> > > > it
> > > > > to
> > > > > > > > JSON
> > > > > > > > > > and YAML?
> > > > > > > > > >
> > > > > > > > > > <goog_787531833>
> > > > > > > > > > https://apacheignite-net.readme.io/docs/configuration
> > > > > > > > > >
> > > > > > > > > > It should be fairly robust, and there's much less
> > > boilerplate.
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Ilya Kasnacheev
> > > > > > > > > >
> > > > > > > > > > 2018-05-15 16:09 GMT+03:00 Pavel Kovalenko <
> > > jokserfn@gmail.com
> > > > >:
> > > > > > > > > >
> > > > > > > > > > > +1 to Dmitriy G. proposal.
> > > > > > > > > > >
> > > > > > > > > > > Since we're moving Ignite towards outside of Java
> world,
> > we
> > > > > > should
> > > > > > > > > > > definitely care about config usability for users who
> are
> > > not
> > > > > > > familiar
> > > > > > > > > > with
> > > > > > > > > > > Java/Spring.
> > > > > > > > > > > If we take a look at any of our XML-configs, we can
> see a
> > > lot
> > > > > of
> > > > > > > > > > > boilerplate like "<bean class="">", "<property
> name="">"
> > -
> > > > > terms
> > > > > > > > which
> > > > > > > > > > say
> > > > > > > > > > > nothing to users outside of Java world.
> > > > > > > > > > > When I see such configs my eyes are filled with bloody
> > > tears.
> > > > > > > > > > >
> > > > > > > > > > > I think we should really consider YAML as our
> additional
> > > > > approach
> > > > > > > to
> > > > > > > > > > > configure Ignite with full replacement instead of XML
> in
> > > > > future.
> > > > > > > > > > > Comparing to XML, YAML is significantly more
> > human-readable
> > > > and
> > > > > > > > > > lightweight
> > > > > > > > > > > format and has stable Java library to parse and
> translate
> > > > > config
> > > > > > > > files
> > > > > > > > > to
> > > > > > > > > > > Java objects without extra-magic.
> > > > > > > > > > >
> > > > > > > > > > > We can find a lot of famous projects which are using
> > YAML:
> > > > > Apache
> > > > > > > > > Flink,
> > > > > > > > > > > Apache Storm/Heron and one of the our main rivals -
> > Apache
> > > > > > > Cassandra.
> > > > > > > > > > >
> > > > > > > > > > > Some of the projects use simple <property>=<name>
> config
> > > form
> > > > > > > (Kafka,
> > > > > > > > > > > Spark), some of the projects use their own YAML-like
> > format
> > > > > > > > (Aerospike,
> > > > > > > > > > > Tarantool), but it's really difficult to find such
> > project
> > > > > which
> > > > > > > has
> > > > > > > > so
> > > > > > > > > > > heavy config as us (maybe VoltDB).
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 2018-05-15 14:02 GMT+03:00 Andrey Gura <
> agura@apache.org
> > >:
> > > > > > > > > > >
> > > > > > > > > > > > Actually sometimes users ask about JSON configuration
> > > (e.g.
> > > > > was
> > > > > > > PR
> > > > > > > > in
> > > > > > > > > > > > vertx-ignite project). But it's non trivial task
> > because
> > > it
> > > > > > will
> > > > > > > > > > > > require development of some DSL (or set of DSL's) and
> > > will
> > > > > make
> > > > > > > > > adding
> > > > > > > > > > > > new configuration elements some kind of pain while we
> > > > should
> > > > > be
> > > > > > > > > > > > focused on basic functionality: data grid,
> persistence,
> > > > etc.
> > > > > > > > > > > >
> > > > > > > > > > > > I just believe that configuration format is not so
> > > > important
> > > > > > > aspect
> > > > > > > > > > > > and this task is out of product scope.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, May 15, 2018 at 12:56 PM, Dmitriy Setrakyan
> > > > > > > > > > > > <ds...@apache.org> wrote:
> > > > > > > > > > > > > I still do not understand *why* do we need to add
> > > > > additional
> > > > > > > > > formats
> > > > > > > > > > > for
> > > > > > > > > > > > > the configuration. Can you please show me some
> users
> > on
> > > > the
> > > > > > > user@
> > > > > > > > > > list
> > > > > > > > > > > > or
> > > > > > > > > > > > > stack overflow who asked for it? I just want to
> make
> > > sure
> > > > > > that
> > > > > > > if
> > > > > > > > > we
> > > > > > > > > > > are
> > > > > > > > > > > > > creating work for ourselves, then someone actually
> > > needs
> > > > > it.
> > > > > > > > > > > > >
> > > > > > > > > > > > > D.
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, May 15, 2018 at 12:41 PM, Igor Sapego <
> > > > > > > > isapego@apache.org>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > >> I don't think we need to add new formats on server
> > > side
> > > > as
> > > > > > > there
> > > > > > > > > may
> > > > > > > > > > > > >> be a lot of different formats for different
> clients.
> > > On
> > > > > the
> > > > > > > > other
> > > > > > > > > > > hand,
> > > > > > > > > > > > >> supporting additional formats may be non trivial
> and
> > > > > > > > error-prone,
> > > > > > > > > > > while
> > > > > > > > > > > > >> adding little to a user experience.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> For clients, I see no problem in adding for
> example
> > > JSON
> > > > > ->
> > > > > > > XML
> > > > > > > > > > > > >> converter on client side, if JS folks need it.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> For servers, adding another configuration format
> > just
> > > to
> > > > > > make
> > > > > > > it
> > > > > > > > > > more
> > > > > > > > > > > > >> familiar to users with no Java background seems
> > > > > unreasonable
> > > > > > > to
> > > > > > > > me
> > > > > > > > > > > > >> as well, as there still going to be Java class
> names
> > > in
> > > > > > > > > > configuration
> > > > > > > > > > > > >> and Spring approach in general.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> What will change is a XML formatting is going to
> > > change
> > > > to
> > > > > > > JSON
> > > > > > > > > > > > >> formatting, which has no much sense to me, as
> > everyone
> > > > > know
> > > > > > > XML.
> > > > > > > > > > > > >> It is Spring approach what can be confusing to
> > > non-Java
> > > > > > users,
> > > > > > > > and
> > > > > > > > > > > > >> it is not going to change regardless of format.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> Best Regards,
> > > > > > > > > > > > >> Igor
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> On Tue, May 15, 2018 at 12:15 PM, Dmitriy
> > Govorukhin <
> > > > > > > > > > > > >> dmitriy.govorukhin@gmail.com> wrote:
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> > Folks,
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >> > I guess when work on a thin client will be
> > > completed,
> > > > we
> > > > > > get
> > > > > > > > > more
> > > > > > > > > > > > >> newcomers
> > > > > > > > > > > > >> > who use go/python/php/js.
> > > > > > > > > > > > >> > And we can do ignite more friendly for them,
> > support
> > > > > > > familiar
> > > > > > > > > > > formats
> > > > > > > > > > > > for
> > > > > > > > > > > > >> > configuration.
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >> > On Tue, May 15, 2018 at 12:13 PM, Dmitry Pavlov
> <
> > > > > > > > > > > > dpavlov.spb@gmail.com>
> > > > > > > > > > > > >> > wrote:
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >> > > Hi Igniters,
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> > > In general I aggree with adding new format,
> e.g.
> > > > JSON
> > > > > is
> > > > > > > > more
> > > > > > > > > > > > popular
> > > > > > > > > > > > >> > than
> > > > > > > > > > > > >> > > XML for new applications.
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> > > In the same time I've never heard that user
> > asked
> > > > this
> > > > > > in
> > > > > > > > the
> > > > > > > > > > user
> > > > > > > > > > > > >> list.
> > > > > > > > > > > > >> > Or
> > > > > > > > > > > > >> > > did I missed such topics?
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> > > Sincerely,
> > > > > > > > > > > > >> > > Dmitriy Pavlov
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> > > вт, 15 мая 2018 г. в 9:31, Pavel Tupitsyn <
> > > > > > > > > ptupitsyn@apache.org
> > > > > > > > > > >:
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> > > > Dmitriy,
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > We don't need to support different config
> > > formats
> > > > on
> > > > > > > > server
> > > > > > > > > in
> > > > > > > > > > > > order
> > > > > > > > > > > > >> to
> > > > > > > > > > > > >> > > add
> > > > > > > > > > > > >> > > > that to thin clients.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > Thin client protocol provides a way to
> create
> > a
> > > > > cache
> > > > > > > with
> > > > > > > > > > > custom
> > > > > > > > > > > > >> > config
> > > > > > > > > > > > >> > > > [1].
> > > > > > > > > > > > >> > > > It is up to thin client library authors to
> use
> > > any
> > > > > > > config
> > > > > > > > > > format
> > > > > > > > > > > > they
> > > > > > > > > > > > >> > > like
> > > > > > > > > > > > >> > > > and then convert it into protocol-defined
> > > format.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > C# thin client uses custom format, for
> > example,
> > > > not
> > > > > > > > Spring.
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > [1]
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > https://apacheignite.readme.
> > > > io/docs/binary-client-
> > > > > > > > > > > > >> > > protocol-cache-configuration-
> > > > > > operations#section-op_cache_
> > > > > > > > > > > > >> > > create_with_configuration
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > On Mon, May 14, 2018 at 7:54 PM, Ivan Rakov
> <
> > > > > > > > > > > > ivan.glukos@gmail.com>
> > > > > > > > > > > > >> > > wrote:
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > > > > Dmitry,
> > > > > > > > > > > > >> > > > >
> > > > > > > > > > > > >> > > > > We rely on Spring Framework when we start
> > > Ignite
> > > > > > node
> > > > > > > > from
> > > > > > > > > > XML
> > > > > > > > > > > > >> > > > > configuration. Spring doesn't easily
> support
> > > > > another
> > > > > > > > > formats
> > > > > > > > > > > of
> > > > > > > > > > > > >> > > > > configuration files. I think, the main
> > reason
> > > > for
> > > > > > this
> > > > > > > > is
> > > > > > > > > > > > built-in
> > > > > > > > > > > > >> > > > ability
> > > > > > > > > > > > >> > > > > to validate configuration via XML Schema.
> We
> > > can
> > > > > > > surely
> > > > > > > > > hack
> > > > > > > > > > > > this
> > > > > > > > > > > > >> > > around
> > > > > > > > > > > > >> > > > (I
> > > > > > > > > > > > >> > > > > bet there are existing libraries for
> > > configuring
> > > > > > > Spring
> > > > > > > > > with
> > > > > > > > > > > > JSON),
> > > > > > > > > > > > >> > > but I
> > > > > > > > > > > > >> > > > > don't think that anyone suffered from
> > > inability
> > > > to
> > > > > > > > > > statically
> > > > > > > > > > > > >> > configure
> > > > > > > > > > > > >> > > > > Ignite with json/yaml.
> > > > > > > > > > > > >> > > > >
> > > > > > > > > > > > >> > > > > Regarding thin clients: makes sense. I
> > suppose
> > > > > > > necessary
> > > > > > > > > > > > mappings
> > > > > > > > > > > > >> > will
> > > > > > > > > > > > >> > > be
> > > > > > > > > > > > >> > > > > implemented as a part of thin client.
> > > > > > > > > > > > >> > > > >
> > > > > > > > > > > > >> > > > > Best Regards,
> > > > > > > > > > > > >> > > > > Ivan Rakov
> > > > > > > > > > > > >> > > > >
> > > > > > > > > > > > >> > > > >
> > > > > > > > > > > > >> > > > > On 14.05.2018 18:58, Dmitriy Govorukhin
> > wrote:
> > > > > > > > > > > > >> > > > >
> > > > > > > > > > > > >> > > > >> Hi, Igniters!
> > > > > > > > > > > > >> > > > >>
> > > > > > > > > > > > >> > > > >> As far as I know, many people work on a
> > thin
> > > > > client
> > > > > > > for
> > > > > > > > > > > > different
> > > > > > > > > > > > >> > > > language
> > > > > > > > > > > > >> > > > >> (go,js,php...).
> > > > > > > > > > > > >> > > > >> Are there any reasons why ignite does not
> > > > support
> > > > > > > yaml
> > > > > > > > or
> > > > > > > > > > > json
> > > > > > > > > > > > >> > format
> > > > > > > > > > > > >> > > > for
> > > > > > > > > > > > >> > > > >> configuration? or some other popular
> > format?
> > > > > > > > > > > > >> > > > >> In future, it can help to integrate with
> > thin
> > > > > > > clients,
> > > > > > > > > for
> > > > > > > > > > > > >> example,
> > > > > > > > > > > > >> > js
> > > > > > > > > > > > >> > > > >> client may want to dynamic cache start,
> he
> > > > passes
> > > > > > > cache
> > > > > > > > > > > > >> > configuration
> > > > > > > > > > > > >> > > > (in
> > > > > > > > > > > > >> > > > >> native format, for js it will json)
> through
> > > > TCP,
> > > > > > > Ignite
> > > > > > > > > > node
> > > > > > > > > > > > >> unwrap
> > > > > > > > > > > > >> > > and
> > > > > > > > > > > > >> > > > >> remap to java representation and dynamic
> > > start
> > > > > > cache.
> > > > > > > > > > > > >> > > > >>
> > > > > > > > > > > > >> > > > >>
> > > > > > > > > > > > >> > > > >
> > > > > > > > > > > > >> > > >
> > > > > > > > > > > > >> > >
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best regards,
> > > > >   Andrey Kuznetsov.
> > > > >
> > > >
> > >
> >
>

Re: supporting different configuration format json,yaml...

Posted by Dmitriy Govorukhin <dm...@gmail.com>.

Folks,

Why do you interpret the question as a necessity for action?
In my first message, "Are there any reasons why ignite does not support
yaml or json format for configuration? or some other popular format?"

On Wed, May 16, 2018 at 10:35 AM, Dmitriy Setrakyan <ds...@apache.org>
wrote:

> I generally agree with Andrey Gura. I do not think that the effort required
> to implement another format for configuration justifies the means. Let's
> stick to the Spring configuration.
>
> D.
>
> On Wed, May 16, 2018 at 10:10 AM, Pavel Tupitsyn <pt...@apache.org>
> wrote:
>
> > Andrey G, +1
> >
> >
> > Andrey K,
> >
> > > json-schema
> > It's a draft. XML schema is a mature standard.
> >
> > > eye fatigue
> > Here is Ignite.NET config:  <cacheConfiguration cacheMode='Replicated'
> > name='myCache'   />
> > Equivalent JSON excerpt:  "cacheConfiguration": { "cacheMode":
> > "Replicated", "name": "myCache" }
> > Enough said I guess :)
> >
> >
> >
> > On Wed, May 16, 2018 at 12:48 AM, Andrey Gura <ag...@apache.org> wrote:
> >
> > > Guys,
> > >
> > > Spring is IoC and you can't offer any format that can  replace Spring.
> It
> > > will just limited DSL.
> > >
> > > Once again. We have enough problems with main functionality. Why do you
> > > want to focus on minor features?
> > >
> > >
> > > вт, 15 мая 2018 г., 23:26 Andrey Kuznetsov <st...@gmail.com>:
> > >
> > > > Pavel,
> > > >
> > > > One can use json-schema if necessary. Of course, XML is more powerful
> > in
> > > > many aspects, but produces more eye fatigue for humans. Of course, we
> > are
> > > > to stay with XML if switching to another configuration format
> requires
> > > > significant effort.
> > > >
> > > > BTW, first time I heard about JSON from [1] : " JSON is like XML,
> > except
> > > it
> > > > doesn't suck ".
> > > >
> > > > [1] https://github.com/cajun-jsonapi/cajun-jsonapi/blob/
> > > master/Readme.txt
> > > >
> > > >
> > > > 2018-05-15 22:43 GMT+03:00 Pavel Tupitsyn <pt...@apache.org>:
> > > >
> > > > > JSON sucks for config files anyway, there are no comments, no
> > schemas,
> > > > > quotes are required around keys, etc
> > > > >
> > > > > Just answer one question: what issue are we trying to solve?
> > > > > XML is not a problem IMO, complexity of our config is.
> > > > >
> > > > > On Tue, May 15, 2018 at 8:00 PM, Igor Sapego <is...@apache.org>
> > > wrote:
> > > > >
> > > > > > How are you going to translate this YAML config to Spring config?
> > > > > >
> > > > > > How would you deal with something like [1]?
> > > > > >
> > > > > > [1] -
> > > > > > https://github.com/apache/ignite/blob/master/modules/
> > > > > > platforms/cpp/odbc-test/config/queries-ssl-32.xml
> > > > > >
> > > > > > Best Regards,
> > > > > > Igor
> > > > > >
> > > > > > On Tue, May 15, 2018 at 7:10 PM, Pavel Kovalenko <
> > jokserfn@gmail.com
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Igor,
> > > > > > >
> > > > > > > Just get one of the config samples and translate it directly to
> > > YAML:
> > > > > > > XML - https://pastebin.com/wtQXXq8f
> > > > > > > YAML - https://pastebin.com/akGu3e81
> > > > > > >
> > > > > > > 2018-05-15 18:49 GMT+03:00 Igor Sapego <is...@apache.org>:
> > > > > > >
> > > > > > > > Guys, if you think the YAML or JSON would be better, how
> about
> > > > > > > > you provide us a brief example of how such configs are going
> to
> > > > > > > > look, so we can compare and see, if this ever have any sense.
> > > > > > > >
> > > > > > > > Best Regards,
> > > > > > > > Igor
> > > > > > > >
> > > > > > > > On Tue, May 15, 2018 at 4:20 PM, Ilya Kasnacheev <
> > > > > > > > ilya.kasnacheev@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hello!
> > > > > > > > >
> > > > > > > > > Maybe we should take .Net configuration as a standard,
> extend
> > > it
> > > > to
> > > > > > > JSON
> > > > > > > > > and YAML?
> > > > > > > > >
> > > > > > > > > <goog_787531833>
> > > > > > > > > https://apacheignite-net.readme.io/docs/configuration
> > > > > > > > >
> > > > > > > > > It should be fairly robust, and there's much less
> > boilerplate.
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Ilya Kasnacheev
> > > > > > > > >
> > > > > > > > > 2018-05-15 16:09 GMT+03:00 Pavel Kovalenko <
> > jokserfn@gmail.com
> > > >:
> > > > > > > > >
> > > > > > > > > > +1 to Dmitriy G. proposal.
> > > > > > > > > >
> > > > > > > > > > Since we're moving Ignite towards outside of Java world,
> we
> > > > > should
> > > > > > > > > > definitely care about config usability for users who are
> > not
> > > > > > familiar
> > > > > > > > > with
> > > > > > > > > > Java/Spring.
> > > > > > > > > > If we take a look at any of our XML-configs, we can see a
> > lot
> > > > of
> > > > > > > > > > boilerplate like "<bean class="">", "<property name="">"
> -
> > > > terms
> > > > > > > which
> > > > > > > > > say
> > > > > > > > > > nothing to users outside of Java world.
> > > > > > > > > > When I see such configs my eyes are filled with bloody
> > tears.
> > > > > > > > > >
> > > > > > > > > > I think we should really consider YAML as our additional
> > > > approach
> > > > > > to
> > > > > > > > > > configure Ignite with full replacement instead of XML in
> > > > future.
> > > > > > > > > > Comparing to XML, YAML is significantly more
> human-readable
> > > and
> > > > > > > > > lightweight
> > > > > > > > > > format and has stable Java library to parse and translate
> > > > config
> > > > > > > files
> > > > > > > > to
> > > > > > > > > > Java objects without extra-magic.
> > > > > > > > > >
> > > > > > > > > > We can find a lot of famous projects which are using
> YAML:
> > > > Apache
> > > > > > > > Flink,
> > > > > > > > > > Apache Storm/Heron and one of the our main rivals -
> Apache
> > > > > > Cassandra.
> > > > > > > > > >
> > > > > > > > > > Some of the projects use simple <property>=<name> config
> > form
> > > > > > (Kafka,
> > > > > > > > > > Spark), some of the projects use their own YAML-like
> format
> > > > > > > (Aerospike,
> > > > > > > > > > Tarantool), but it's really difficult to find such
> project
> > > > which
> > > > > > has
> > > > > > > so
> > > > > > > > > > heavy config as us (maybe VoltDB).
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 2018-05-15 14:02 GMT+03:00 Andrey Gura <agura@apache.org
> >:
> > > > > > > > > >
> > > > > > > > > > > Actually sometimes users ask about JSON configuration
> > (e.g.
> > > > was
> > > > > > PR
> > > > > > > in
> > > > > > > > > > > vertx-ignite project). But it's non trivial task
> because
> > it
> > > > > will
> > > > > > > > > > > require development of some DSL (or set of DSL's) and
> > will
> > > > make
> > > > > > > > adding
> > > > > > > > > > > new configuration elements some kind of pain while we
> > > should
> > > > be
> > > > > > > > > > > focused on basic functionality: data grid, persistence,
> > > etc.
> > > > > > > > > > >
> > > > > > > > > > > I just believe that configuration format is not so
> > > important
> > > > > > aspect
> > > > > > > > > > > and this task is out of product scope.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Tue, May 15, 2018 at 12:56 PM, Dmitriy Setrakyan
> > > > > > > > > > > <ds...@apache.org> wrote:
> > > > > > > > > > > > I still do not understand *why* do we need to add
> > > > additional
> > > > > > > > formats
> > > > > > > > > > for
> > > > > > > > > > > > the configuration. Can you please show me some users
> on
> > > the
> > > > > > user@
> > > > > > > > > list
> > > > > > > > > > > or
> > > > > > > > > > > > stack overflow who asked for it? I just want to make
> > sure
> > > > > that
> > > > > > if
> > > > > > > > we
> > > > > > > > > > are
> > > > > > > > > > > > creating work for ourselves, then someone actually
> > needs
> > > > it.
> > > > > > > > > > > >
> > > > > > > > > > > > D.
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, May 15, 2018 at 12:41 PM, Igor Sapego <
> > > > > > > isapego@apache.org>
> > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > >> I don't think we need to add new formats on server
> > side
> > > as
> > > > > > there
> > > > > > > > may
> > > > > > > > > > > >> be a lot of different formats for different clients.
> > On
> > > > the
> > > > > > > other
> > > > > > > > > > hand,
> > > > > > > > > > > >> supporting additional formats may be non trivial and
> > > > > > > error-prone,
> > > > > > > > > > while
> > > > > > > > > > > >> adding little to a user experience.
> > > > > > > > > > > >>
> > > > > > > > > > > >> For clients, I see no problem in adding for example
> > JSON
> > > > ->
> > > > > > XML
> > > > > > > > > > > >> converter on client side, if JS folks need it.
> > > > > > > > > > > >>
> > > > > > > > > > > >> For servers, adding another configuration format
> just
> > to
> > > > > make
> > > > > > it
> > > > > > > > > more
> > > > > > > > > > > >> familiar to users with no Java background seems
> > > > unreasonable
> > > > > > to
> > > > > > > me
> > > > > > > > > > > >> as well, as there still going to be Java class names
> > in
> > > > > > > > > configuration
> > > > > > > > > > > >> and Spring approach in general.
> > > > > > > > > > > >>
> > > > > > > > > > > >> What will change is a XML formatting is going to
> > change
> > > to
> > > > > > JSON
> > > > > > > > > > > >> formatting, which has no much sense to me, as
> everyone
> > > > know
> > > > > > XML.
> > > > > > > > > > > >> It is Spring approach what can be confusing to
> > non-Java
> > > > > users,
> > > > > > > and
> > > > > > > > > > > >> it is not going to change regardless of format.
> > > > > > > > > > > >>
> > > > > > > > > > > >> Best Regards,
> > > > > > > > > > > >> Igor
> > > > > > > > > > > >>
> > > > > > > > > > > >> On Tue, May 15, 2018 at 12:15 PM, Dmitriy
> Govorukhin <
> > > > > > > > > > > >> dmitriy.govorukhin@gmail.com> wrote:
> > > > > > > > > > > >>
> > > > > > > > > > > >> > Folks,
> > > > > > > > > > > >> >
> > > > > > > > > > > >> > I guess when work on a thin client will be
> > completed,
> > > we
> > > > > get
> > > > > > > > more
> > > > > > > > > > > >> newcomers
> > > > > > > > > > > >> > who use go/python/php/js.
> > > > > > > > > > > >> > And we can do ignite more friendly for them,
> support
> > > > > > familiar
> > > > > > > > > > formats
> > > > > > > > > > > for
> > > > > > > > > > > >> > configuration.
> > > > > > > > > > > >> >
> > > > > > > > > > > >> > On Tue, May 15, 2018 at 12:13 PM, Dmitry Pavlov <
> > > > > > > > > > > dpavlov.spb@gmail.com>
> > > > > > > > > > > >> > wrote:
> > > > > > > > > > > >> >
> > > > > > > > > > > >> > > Hi Igniters,
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > In general I aggree with adding new format, e.g.
> > > JSON
> > > > is
> > > > > > > more
> > > > > > > > > > > popular
> > > > > > > > > > > >> > than
> > > > > > > > > > > >> > > XML for new applications.
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > In the same time I've never heard that user
> asked
> > > this
> > > > > in
> > > > > > > the
> > > > > > > > > user
> > > > > > > > > > > >> list.
> > > > > > > > > > > >> > Or
> > > > > > > > > > > >> > > did I missed such topics?
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > Sincerely,
> > > > > > > > > > > >> > > Dmitriy Pavlov
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > вт, 15 мая 2018 г. в 9:31, Pavel Tupitsyn <
> > > > > > > > ptupitsyn@apache.org
> > > > > > > > > >:
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > > Dmitriy,
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > We don't need to support different config
> > formats
> > > on
> > > > > > > server
> > > > > > > > in
> > > > > > > > > > > order
> > > > > > > > > > > >> to
> > > > > > > > > > > >> > > add
> > > > > > > > > > > >> > > > that to thin clients.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > Thin client protocol provides a way to create
> a
> > > > cache
> > > > > > with
> > > > > > > > > > custom
> > > > > > > > > > > >> > config
> > > > > > > > > > > >> > > > [1].
> > > > > > > > > > > >> > > > It is up to thin client library authors to use
> > any
> > > > > > config
> > > > > > > > > format
> > > > > > > > > > > they
> > > > > > > > > > > >> > > like
> > > > > > > > > > > >> > > > and then convert it into protocol-defined
> > format.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > C# thin client uses custom format, for
> example,
> > > not
> > > > > > > Spring.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > [1]
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > https://apacheignite.readme.
> > > io/docs/binary-client-
> > > > > > > > > > > >> > > protocol-cache-configuration-
> > > > > operations#section-op_cache_
> > > > > > > > > > > >> > > create_with_configuration
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > On Mon, May 14, 2018 at 7:54 PM, Ivan Rakov <
> > > > > > > > > > > ivan.glukos@gmail.com>
> > > > > > > > > > > >> > > wrote:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > > Dmitry,
> > > > > > > > > > > >> > > > >
> > > > > > > > > > > >> > > > > We rely on Spring Framework when we start
> > Ignite
> > > > > node
> > > > > > > from
> > > > > > > > > XML
> > > > > > > > > > > >> > > > > configuration. Spring doesn't easily support
> > > > another
> > > > > > > > formats
> > > > > > > > > > of
> > > > > > > > > > > >> > > > > configuration files. I think, the main
> reason
> > > for
> > > > > this
> > > > > > > is
> > > > > > > > > > > built-in
> > > > > > > > > > > >> > > > ability
> > > > > > > > > > > >> > > > > to validate configuration via XML Schema. We
> > can
> > > > > > surely
> > > > > > > > hack
> > > > > > > > > > > this
> > > > > > > > > > > >> > > around
> > > > > > > > > > > >> > > > (I
> > > > > > > > > > > >> > > > > bet there are existing libraries for
> > configuring
> > > > > > Spring
> > > > > > > > with
> > > > > > > > > > > JSON),
> > > > > > > > > > > >> > > but I
> > > > > > > > > > > >> > > > > don't think that anyone suffered from
> > inability
> > > to
> > > > > > > > > statically
> > > > > > > > > > > >> > configure
> > > > > > > > > > > >> > > > > Ignite with json/yaml.
> > > > > > > > > > > >> > > > >
> > > > > > > > > > > >> > > > > Regarding thin clients: makes sense. I
> suppose
> > > > > > necessary
> > > > > > > > > > > mappings
> > > > > > > > > > > >> > will
> > > > > > > > > > > >> > > be
> > > > > > > > > > > >> > > > > implemented as a part of thin client.
> > > > > > > > > > > >> > > > >
> > > > > > > > > > > >> > > > > Best Regards,
> > > > > > > > > > > >> > > > > Ivan Rakov
> > > > > > > > > > > >> > > > >
> > > > > > > > > > > >> > > > >
> > > > > > > > > > > >> > > > > On 14.05.2018 18:58, Dmitriy Govorukhin
> wrote:
> > > > > > > > > > > >> > > > >
> > > > > > > > > > > >> > > > >> Hi, Igniters!
> > > > > > > > > > > >> > > > >>
> > > > > > > > > > > >> > > > >> As far as I know, many people work on a
> thin
> > > > client
> > > > > > for
> > > > > > > > > > > different
> > > > > > > > > > > >> > > > language
> > > > > > > > > > > >> > > > >> (go,js,php...).
> > > > > > > > > > > >> > > > >> Are there any reasons why ignite does not
> > > support
> > > > > > yaml
> > > > > > > or
> > > > > > > > > > json
> > > > > > > > > > > >> > format
> > > > > > > > > > > >> > > > for
> > > > > > > > > > > >> > > > >> configuration? or some other popular
> format?
> > > > > > > > > > > >> > > > >> In future, it can help to integrate with
> thin
> > > > > > clients,
> > > > > > > > for
> > > > > > > > > > > >> example,
> > > > > > > > > > > >> > js
> > > > > > > > > > > >> > > > >> client may want to dynamic cache start, he
> > > passes
> > > > > > cache
> > > > > > > > > > > >> > configuration
> > > > > > > > > > > >> > > > (in
> > > > > > > > > > > >> > > > >> native format, for js it will json) through
> > > TCP,
> > > > > > Ignite
> > > > > > > > > node
> > > > > > > > > > > >> unwrap
> > > > > > > > > > > >> > > and
> > > > > > > > > > > >> > > > >> remap to java representation and dynamic
> > start
> > > > > cache.
> > > > > > > > > > > >> > > > >>
> > > > > > > > > > > >> > > > >>
> > > > > > > > > > > >> > > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > >   Andrey Kuznetsov.
> > > >
> > >
> >
>

Re: supporting different configuration format json,yaml...

Posted by Dmitriy Setrakyan <ds...@apache.org>.

I generally agree with Andrey Gura. I do not think that the effort required
to implement another format for configuration justifies the means. Let's
stick to the Spring configuration.

D.

On Wed, May 16, 2018 at 10:10 AM, Pavel Tupitsyn <pt...@apache.org>
wrote:

> Andrey G, +1
>
>
> Andrey K,
>
> > json-schema
> It's a draft. XML schema is a mature standard.
>
> > eye fatigue
> Here is Ignite.NET config:  <cacheConfiguration cacheMode='Replicated'
> name='myCache'   />
> Equivalent JSON excerpt:  "cacheConfiguration": { "cacheMode":
> "Replicated", "name": "myCache" }
> Enough said I guess :)
>
>
>
> On Wed, May 16, 2018 at 12:48 AM, Andrey Gura <ag...@apache.org> wrote:
>
> > Guys,
> >
> > Spring is IoC and you can't offer any format that can  replace Spring. It
> > will just limited DSL.
> >
> > Once again. We have enough problems with main functionality. Why do you
> > want to focus on minor features?
> >
> >
> > вт, 15 мая 2018 г., 23:26 Andrey Kuznetsov <st...@gmail.com>:
> >
> > > Pavel,
> > >
> > > One can use json-schema if necessary. Of course, XML is more powerful
> in
> > > many aspects, but produces more eye fatigue for humans. Of course, we
> are
> > > to stay with XML if switching to another configuration format requires
> > > significant effort.
> > >
> > > BTW, first time I heard about JSON from [1] : " JSON is like XML,
> except
> > it
> > > doesn't suck ".
> > >
> > > [1] https://github.com/cajun-jsonapi/cajun-jsonapi/blob/
> > master/Readme.txt
> > >
> > >
> > > 2018-05-15 22:43 GMT+03:00 Pavel Tupitsyn <pt...@apache.org>:
> > >
> > > > JSON sucks for config files anyway, there are no comments, no
> schemas,
> > > > quotes are required around keys, etc
> > > >
> > > > Just answer one question: what issue are we trying to solve?
> > > > XML is not a problem IMO, complexity of our config is.
> > > >
> > > > On Tue, May 15, 2018 at 8:00 PM, Igor Sapego <is...@apache.org>
> > wrote:
> > > >
> > > > > How are you going to translate this YAML config to Spring config?
> > > > >
> > > > > How would you deal with something like [1]?
> > > > >
> > > > > [1] -
> > > > > https://github.com/apache/ignite/blob/master/modules/
> > > > > platforms/cpp/odbc-test/config/queries-ssl-32.xml
> > > > >
> > > > > Best Regards,
> > > > > Igor
> > > > >
> > > > > On Tue, May 15, 2018 at 7:10 PM, Pavel Kovalenko <
> jokserfn@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > Igor,
> > > > > >
> > > > > > Just get one of the config samples and translate it directly to
> > YAML:
> > > > > > XML - https://pastebin.com/wtQXXq8f
> > > > > > YAML - https://pastebin.com/akGu3e81
> > > > > >
> > > > > > 2018-05-15 18:49 GMT+03:00 Igor Sapego <is...@apache.org>:
> > > > > >
> > > > > > > Guys, if you think the YAML or JSON would be better, how about
> > > > > > > you provide us a brief example of how such configs are going to
> > > > > > > look, so we can compare and see, if this ever have any sense.
> > > > > > >
> > > > > > > Best Regards,
> > > > > > > Igor
> > > > > > >
> > > > > > > On Tue, May 15, 2018 at 4:20 PM, Ilya Kasnacheev <
> > > > > > > ilya.kasnacheev@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hello!
> > > > > > > >
> > > > > > > > Maybe we should take .Net configuration as a standard, extend
> > it
> > > to
> > > > > > JSON
> > > > > > > > and YAML?
> > > > > > > >
> > > > > > > > <goog_787531833>
> > > > > > > > https://apacheignite-net.readme.io/docs/configuration
> > > > > > > >
> > > > > > > > It should be fairly robust, and there's much less
> boilerplate.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Ilya Kasnacheev
> > > > > > > >
> > > > > > > > 2018-05-15 16:09 GMT+03:00 Pavel Kovalenko <
> jokserfn@gmail.com
> > >:
> > > > > > > >
> > > > > > > > > +1 to Dmitriy G. proposal.
> > > > > > > > >
> > > > > > > > > Since we're moving Ignite towards outside of Java world, we
> > > > should
> > > > > > > > > definitely care about config usability for users who are
> not
> > > > > familiar
> > > > > > > > with
> > > > > > > > > Java/Spring.
> > > > > > > > > If we take a look at any of our XML-configs, we can see a
> lot
> > > of
> > > > > > > > > boilerplate like "<bean class="">", "<property name="">" -
> > > terms
> > > > > > which
> > > > > > > > say
> > > > > > > > > nothing to users outside of Java world.
> > > > > > > > > When I see such configs my eyes are filled with bloody
> tears.
> > > > > > > > >
> > > > > > > > > I think we should really consider YAML as our additional
> > > approach
> > > > > to
> > > > > > > > > configure Ignite with full replacement instead of XML in
> > > future.
> > > > > > > > > Comparing to XML, YAML is significantly more human-readable
> > and
> > > > > > > > lightweight
> > > > > > > > > format and has stable Java library to parse and translate
> > > config
> > > > > > files
> > > > > > > to
> > > > > > > > > Java objects without extra-magic.
> > > > > > > > >
> > > > > > > > > We can find a lot of famous projects which are using YAML:
> > > Apache
> > > > > > > Flink,
> > > > > > > > > Apache Storm/Heron and one of the our main rivals - Apache
> > > > > Cassandra.
> > > > > > > > >
> > > > > > > > > Some of the projects use simple <property>=<name> config
> form
> > > > > (Kafka,
> > > > > > > > > Spark), some of the projects use their own YAML-like format
> > > > > > (Aerospike,
> > > > > > > > > Tarantool), but it's really difficult to find such project
> > > which
> > > > > has
> > > > > > so
> > > > > > > > > heavy config as us (maybe VoltDB).
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > 2018-05-15 14:02 GMT+03:00 Andrey Gura <ag...@apache.org>:
> > > > > > > > >
> > > > > > > > > > Actually sometimes users ask about JSON configuration
> (e.g.
> > > was
> > > > > PR
> > > > > > in
> > > > > > > > > > vertx-ignite project). But it's non trivial task because
> it
> > > > will
> > > > > > > > > > require development of some DSL (or set of DSL's) and
> will
> > > make
> > > > > > > adding
> > > > > > > > > > new configuration elements some kind of pain while we
> > should
> > > be
> > > > > > > > > > focused on basic functionality: data grid, persistence,
> > etc.
> > > > > > > > > >
> > > > > > > > > > I just believe that configuration format is not so
> > important
> > > > > aspect
> > > > > > > > > > and this task is out of product scope.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Tue, May 15, 2018 at 12:56 PM, Dmitriy Setrakyan
> > > > > > > > > > <ds...@apache.org> wrote:
> > > > > > > > > > > I still do not understand *why* do we need to add
> > > additional
> > > > > > > formats
> > > > > > > > > for
> > > > > > > > > > > the configuration. Can you please show me some users on
> > the
> > > > > user@
> > > > > > > > list
> > > > > > > > > > or
> > > > > > > > > > > stack overflow who asked for it? I just want to make
> sure
> > > > that
> > > > > if
> > > > > > > we
> > > > > > > > > are
> > > > > > > > > > > creating work for ourselves, then someone actually
> needs
> > > it.
> > > > > > > > > > >
> > > > > > > > > > > D.
> > > > > > > > > > >
> > > > > > > > > > > On Tue, May 15, 2018 at 12:41 PM, Igor Sapego <
> > > > > > isapego@apache.org>
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > >> I don't think we need to add new formats on server
> side
> > as
> > > > > there
> > > > > > > may
> > > > > > > > > > >> be a lot of different formats for different clients.
> On
> > > the
> > > > > > other
> > > > > > > > > hand,
> > > > > > > > > > >> supporting additional formats may be non trivial and
> > > > > > error-prone,
> > > > > > > > > while
> > > > > > > > > > >> adding little to a user experience.
> > > > > > > > > > >>
> > > > > > > > > > >> For clients, I see no problem in adding for example
> JSON
> > > ->
> > > > > XML
> > > > > > > > > > >> converter on client side, if JS folks need it.
> > > > > > > > > > >>
> > > > > > > > > > >> For servers, adding another configuration format just
> to
> > > > make
> > > > > it
> > > > > > > > more
> > > > > > > > > > >> familiar to users with no Java background seems
> > > unreasonable
> > > > > to
> > > > > > me
> > > > > > > > > > >> as well, as there still going to be Java class names
> in
> > > > > > > > configuration
> > > > > > > > > > >> and Spring approach in general.
> > > > > > > > > > >>
> > > > > > > > > > >> What will change is a XML formatting is going to
> change
> > to
> > > > > JSON
> > > > > > > > > > >> formatting, which has no much sense to me, as everyone
> > > know
> > > > > XML.
> > > > > > > > > > >> It is Spring approach what can be confusing to
> non-Java
> > > > users,
> > > > > > and
> > > > > > > > > > >> it is not going to change regardless of format.
> > > > > > > > > > >>
> > > > > > > > > > >> Best Regards,
> > > > > > > > > > >> Igor
> > > > > > > > > > >>
> > > > > > > > > > >> On Tue, May 15, 2018 at 12:15 PM, Dmitriy Govorukhin <
> > > > > > > > > > >> dmitriy.govorukhin@gmail.com> wrote:
> > > > > > > > > > >>
> > > > > > > > > > >> > Folks,
> > > > > > > > > > >> >
> > > > > > > > > > >> > I guess when work on a thin client will be
> completed,
> > we
> > > > get
> > > > > > > more
> > > > > > > > > > >> newcomers
> > > > > > > > > > >> > who use go/python/php/js.
> > > > > > > > > > >> > And we can do ignite more friendly for them, support
> > > > > familiar
> > > > > > > > > formats
> > > > > > > > > > for
> > > > > > > > > > >> > configuration.
> > > > > > > > > > >> >
> > > > > > > > > > >> > On Tue, May 15, 2018 at 12:13 PM, Dmitry Pavlov <
> > > > > > > > > > dpavlov.spb@gmail.com>
> > > > > > > > > > >> > wrote:
> > > > > > > > > > >> >
> > > > > > > > > > >> > > Hi Igniters,
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > In general I aggree with adding new format, e.g.
> > JSON
> > > is
> > > > > > more
> > > > > > > > > > popular
> > > > > > > > > > >> > than
> > > > > > > > > > >> > > XML for new applications.
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > In the same time I've never heard that user asked
> > this
> > > > in
> > > > > > the
> > > > > > > > user
> > > > > > > > > > >> list.
> > > > > > > > > > >> > Or
> > > > > > > > > > >> > > did I missed such topics?
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > Sincerely,
> > > > > > > > > > >> > > Dmitriy Pavlov
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > вт, 15 мая 2018 г. в 9:31, Pavel Tupitsyn <
> > > > > > > ptupitsyn@apache.org
> > > > > > > > >:
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > > Dmitriy,
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > We don't need to support different config
> formats
> > on
> > > > > > server
> > > > > > > in
> > > > > > > > > > order
> > > > > > > > > > >> to
> > > > > > > > > > >> > > add
> > > > > > > > > > >> > > > that to thin clients.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > Thin client protocol provides a way to create a
> > > cache
> > > > > with
> > > > > > > > > custom
> > > > > > > > > > >> > config
> > > > > > > > > > >> > > > [1].
> > > > > > > > > > >> > > > It is up to thin client library authors to use
> any
> > > > > config
> > > > > > > > format
> > > > > > > > > > they
> > > > > > > > > > >> > > like
> > > > > > > > > > >> > > > and then convert it into protocol-defined
> format.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > C# thin client uses custom format, for example,
> > not
> > > > > > Spring.
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > [1]
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > https://apacheignite.readme.
> > io/docs/binary-client-
> > > > > > > > > > >> > > protocol-cache-configuration-
> > > > operations#section-op_cache_
> > > > > > > > > > >> > > create_with_configuration
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > On Mon, May 14, 2018 at 7:54 PM, Ivan Rakov <
> > > > > > > > > > ivan.glukos@gmail.com>
> > > > > > > > > > >> > > wrote:
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > > Dmitry,
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > > > We rely on Spring Framework when we start
> Ignite
> > > > node
> > > > > > from
> > > > > > > > XML
> > > > > > > > > > >> > > > > configuration. Spring doesn't easily support
> > > another
> > > > > > > formats
> > > > > > > > > of
> > > > > > > > > > >> > > > > configuration files. I think, the main reason
> > for
> > > > this
> > > > > > is
> > > > > > > > > > built-in
> > > > > > > > > > >> > > > ability
> > > > > > > > > > >> > > > > to validate configuration via XML Schema. We
> can
> > > > > surely
> > > > > > > hack
> > > > > > > > > > this
> > > > > > > > > > >> > > around
> > > > > > > > > > >> > > > (I
> > > > > > > > > > >> > > > > bet there are existing libraries for
> configuring
> > > > > Spring
> > > > > > > with
> > > > > > > > > > JSON),
> > > > > > > > > > >> > > but I
> > > > > > > > > > >> > > > > don't think that anyone suffered from
> inability
> > to
> > > > > > > > statically
> > > > > > > > > > >> > configure
> > > > > > > > > > >> > > > > Ignite with json/yaml.
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > > > Regarding thin clients: makes sense. I suppose
> > > > > necessary
> > > > > > > > > > mappings
> > > > > > > > > > >> > will
> > > > > > > > > > >> > > be
> > > > > > > > > > >> > > > > implemented as a part of thin client.
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > > > Best Regards,
> > > > > > > > > > >> > > > > Ivan Rakov
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > > > On 14.05.2018 18:58, Dmitriy Govorukhin wrote:
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > > >> Hi, Igniters!
> > > > > > > > > > >> > > > >>
> > > > > > > > > > >> > > > >> As far as I know, many people work on a thin
> > > client
> > > > > for
> > > > > > > > > > different
> > > > > > > > > > >> > > > language
> > > > > > > > > > >> > > > >> (go,js,php...).
> > > > > > > > > > >> > > > >> Are there any reasons why ignite does not
> > support
> > > > > yaml
> > > > > > or
> > > > > > > > > json
> > > > > > > > > > >> > format
> > > > > > > > > > >> > > > for
> > > > > > > > > > >> > > > >> configuration? or some other popular format?
> > > > > > > > > > >> > > > >> In future, it can help to integrate with thin
> > > > > clients,
> > > > > > > for
> > > > > > > > > > >> example,
> > > > > > > > > > >> > js
> > > > > > > > > > >> > > > >> client may want to dynamic cache start, he
> > passes
> > > > > cache
> > > > > > > > > > >> > configuration
> > > > > > > > > > >> > > > (in
> > > > > > > > > > >> > > > >> native format, for js it will json) through
> > TCP,
> > > > > Ignite
> > > > > > > > node
> > > > > > > > > > >> unwrap
> > > > > > > > > > >> > > and
> > > > > > > > > > >> > > > >> remap to java representation and dynamic
> start
> > > > cache.
> > > > > > > > > > >> > > > >>
> > > > > > > > > > >> > > > >>
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > >   Andrey Kuznetsov.
> > >
> >
>

Re: supporting different configuration format json,yaml...

Posted by Pavel Tupitsyn <pt...@apache.org>.

Andrey G, +1


Andrey K,

> json-schema
It's a draft. XML schema is a mature standard.

> eye fatigue
Here is Ignite.NET config:  <cacheConfiguration cacheMode='Replicated'
name='myCache'   />
Equivalent JSON excerpt:  "cacheConfiguration": { "cacheMode":
"Replicated", "name": "myCache" }
Enough said I guess :)



On Wed, May 16, 2018 at 12:48 AM, Andrey Gura <ag...@apache.org> wrote:

> Guys,
>
> Spring is IoC and you can't offer any format that can  replace Spring. It
> will just limited DSL.
>
> Once again. We have enough problems with main functionality. Why do you
> want to focus on minor features?
>
>
> вт, 15 мая 2018 г., 23:26 Andrey Kuznetsov <st...@gmail.com>:
>
> > Pavel,
> >
> > One can use json-schema if necessary. Of course, XML is more powerful in
> > many aspects, but produces more eye fatigue for humans. Of course, we are
> > to stay with XML if switching to another configuration format requires
> > significant effort.
> >
> > BTW, first time I heard about JSON from [1] : " JSON is like XML, except
> it
> > doesn't suck ".
> >
> > [1] https://github.com/cajun-jsonapi/cajun-jsonapi/blob/
> master/Readme.txt
> >
> >
> > 2018-05-15 22:43 GMT+03:00 Pavel Tupitsyn <pt...@apache.org>:
> >
> > > JSON sucks for config files anyway, there are no comments, no schemas,
> > > quotes are required around keys, etc
> > >
> > > Just answer one question: what issue are we trying to solve?
> > > XML is not a problem IMO, complexity of our config is.
> > >
> > > On Tue, May 15, 2018 at 8:00 PM, Igor Sapego <is...@apache.org>
> wrote:
> > >
> > > > How are you going to translate this YAML config to Spring config?
> > > >
> > > > How would you deal with something like [1]?
> > > >
> > > > [1] -
> > > > https://github.com/apache/ignite/blob/master/modules/
> > > > platforms/cpp/odbc-test/config/queries-ssl-32.xml
> > > >
> > > > Best Regards,
> > > > Igor
> > > >
> > > > On Tue, May 15, 2018 at 7:10 PM, Pavel Kovalenko <jokserfn@gmail.com
> >
> > > > wrote:
> > > >
> > > > > Igor,
> > > > >
> > > > > Just get one of the config samples and translate it directly to
> YAML:
> > > > > XML - https://pastebin.com/wtQXXq8f
> > > > > YAML - https://pastebin.com/akGu3e81
> > > > >
> > > > > 2018-05-15 18:49 GMT+03:00 Igor Sapego <is...@apache.org>:
> > > > >
> > > > > > Guys, if you think the YAML or JSON would be better, how about
> > > > > > you provide us a brief example of how such configs are going to
> > > > > > look, so we can compare and see, if this ever have any sense.
> > > > > >
> > > > > > Best Regards,
> > > > > > Igor
> > > > > >
> > > > > > On Tue, May 15, 2018 at 4:20 PM, Ilya Kasnacheev <
> > > > > > ilya.kasnacheev@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hello!
> > > > > > >
> > > > > > > Maybe we should take .Net configuration as a standard, extend
> it
> > to
> > > > > JSON
> > > > > > > and YAML?
> > > > > > >
> > > > > > > <goog_787531833>
> > > > > > > https://apacheignite-net.readme.io/docs/configuration
> > > > > > >
> > > > > > > It should be fairly robust, and there's much less boilerplate.
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Ilya Kasnacheev
> > > > > > >
> > > > > > > 2018-05-15 16:09 GMT+03:00 Pavel Kovalenko <jokserfn@gmail.com
> >:
> > > > > > >
> > > > > > > > +1 to Dmitriy G. proposal.
> > > > > > > >
> > > > > > > > Since we're moving Ignite towards outside of Java world, we
> > > should
> > > > > > > > definitely care about config usability for users who are not
> > > > familiar
> > > > > > > with
> > > > > > > > Java/Spring.
> > > > > > > > If we take a look at any of our XML-configs, we can see a lot
> > of
> > > > > > > > boilerplate like "<bean class="">", "<property name="">" -
> > terms
> > > > > which
> > > > > > > say
> > > > > > > > nothing to users outside of Java world.
> > > > > > > > When I see such configs my eyes are filled with bloody tears.
> > > > > > > >
> > > > > > > > I think we should really consider YAML as our additional
> > approach
> > > > to
> > > > > > > > configure Ignite with full replacement instead of XML in
> > future.
> > > > > > > > Comparing to XML, YAML is significantly more human-readable
> and
> > > > > > > lightweight
> > > > > > > > format and has stable Java library to parse and translate
> > config
> > > > > files
> > > > > > to
> > > > > > > > Java objects without extra-magic.
> > > > > > > >
> > > > > > > > We can find a lot of famous projects which are using YAML:
> > Apache
> > > > > > Flink,
> > > > > > > > Apache Storm/Heron and one of the our main rivals - Apache
> > > > Cassandra.
> > > > > > > >
> > > > > > > > Some of the projects use simple <property>=<name> config form
> > > > (Kafka,
> > > > > > > > Spark), some of the projects use their own YAML-like format
> > > > > (Aerospike,
> > > > > > > > Tarantool), but it's really difficult to find such project
> > which
> > > > has
> > > > > so
> > > > > > > > heavy config as us (maybe VoltDB).
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > 2018-05-15 14:02 GMT+03:00 Andrey Gura <ag...@apache.org>:
> > > > > > > >
> > > > > > > > > Actually sometimes users ask about JSON configuration (e.g.
> > was
> > > > PR
> > > > > in
> > > > > > > > > vertx-ignite project). But it's non trivial task because it
> > > will
> > > > > > > > > require development of some DSL (or set of DSL's) and will
> > make
> > > > > > adding
> > > > > > > > > new configuration elements some kind of pain while we
> should
> > be
> > > > > > > > > focused on basic functionality: data grid, persistence,
> etc.
> > > > > > > > >
> > > > > > > > > I just believe that configuration format is not so
> important
> > > > aspect
> > > > > > > > > and this task is out of product scope.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Tue, May 15, 2018 at 12:56 PM, Dmitriy Setrakyan
> > > > > > > > > <ds...@apache.org> wrote:
> > > > > > > > > > I still do not understand *why* do we need to add
> > additional
> > > > > > formats
> > > > > > > > for
> > > > > > > > > > the configuration. Can you please show me some users on
> the
> > > > user@
> > > > > > > list
> > > > > > > > > or
> > > > > > > > > > stack overflow who asked for it? I just want to make sure
> > > that
> > > > if
> > > > > > we
> > > > > > > > are
> > > > > > > > > > creating work for ourselves, then someone actually needs
> > it.
> > > > > > > > > >
> > > > > > > > > > D.
> > > > > > > > > >
> > > > > > > > > > On Tue, May 15, 2018 at 12:41 PM, Igor Sapego <
> > > > > isapego@apache.org>
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > >> I don't think we need to add new formats on server side
> as
> > > > there
> > > > > > may
> > > > > > > > > >> be a lot of different formats for different clients. On
> > the
> > > > > other
> > > > > > > > hand,
> > > > > > > > > >> supporting additional formats may be non trivial and
> > > > > error-prone,
> > > > > > > > while
> > > > > > > > > >> adding little to a user experience.
> > > > > > > > > >>
> > > > > > > > > >> For clients, I see no problem in adding for example JSON
> > ->
> > > > XML
> > > > > > > > > >> converter on client side, if JS folks need it.
> > > > > > > > > >>
> > > > > > > > > >> For servers, adding another configuration format just to
> > > make
> > > > it
> > > > > > > more
> > > > > > > > > >> familiar to users with no Java background seems
> > unreasonable
> > > > to
> > > > > me
> > > > > > > > > >> as well, as there still going to be Java class names in
> > > > > > > configuration
> > > > > > > > > >> and Spring approach in general.
> > > > > > > > > >>
> > > > > > > > > >> What will change is a XML formatting is going to change
> to
> > > > JSON
> > > > > > > > > >> formatting, which has no much sense to me, as everyone
> > know
> > > > XML.
> > > > > > > > > >> It is Spring approach what can be confusing to non-Java
> > > users,
> > > > > and
> > > > > > > > > >> it is not going to change regardless of format.
> > > > > > > > > >>
> > > > > > > > > >> Best Regards,
> > > > > > > > > >> Igor
> > > > > > > > > >>
> > > > > > > > > >> On Tue, May 15, 2018 at 12:15 PM, Dmitriy Govorukhin <
> > > > > > > > > >> dmitriy.govorukhin@gmail.com> wrote:
> > > > > > > > > >>
> > > > > > > > > >> > Folks,
> > > > > > > > > >> >
> > > > > > > > > >> > I guess when work on a thin client will be completed,
> we
> > > get
> > > > > > more
> > > > > > > > > >> newcomers
> > > > > > > > > >> > who use go/python/php/js.
> > > > > > > > > >> > And we can do ignite more friendly for them, support
> > > > familiar
> > > > > > > > formats
> > > > > > > > > for
> > > > > > > > > >> > configuration.
> > > > > > > > > >> >
> > > > > > > > > >> > On Tue, May 15, 2018 at 12:13 PM, Dmitry Pavlov <
> > > > > > > > > dpavlov.spb@gmail.com>
> > > > > > > > > >> > wrote:
> > > > > > > > > >> >
> > > > > > > > > >> > > Hi Igniters,
> > > > > > > > > >> > >
> > > > > > > > > >> > > In general I aggree with adding new format, e.g.
> JSON
> > is
> > > > > more
> > > > > > > > > popular
> > > > > > > > > >> > than
> > > > > > > > > >> > > XML for new applications.
> > > > > > > > > >> > >
> > > > > > > > > >> > > In the same time I've never heard that user asked
> this
> > > in
> > > > > the
> > > > > > > user
> > > > > > > > > >> list.
> > > > > > > > > >> > Or
> > > > > > > > > >> > > did I missed such topics?
> > > > > > > > > >> > >
> > > > > > > > > >> > > Sincerely,
> > > > > > > > > >> > > Dmitriy Pavlov
> > > > > > > > > >> > >
> > > > > > > > > >> > > вт, 15 мая 2018 г. в 9:31, Pavel Tupitsyn <
> > > > > > ptupitsyn@apache.org
> > > > > > > >:
> > > > > > > > > >> > >
> > > > > > > > > >> > > > Dmitriy,
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > We don't need to support different config formats
> on
> > > > > server
> > > > > > in
> > > > > > > > > order
> > > > > > > > > >> to
> > > > > > > > > >> > > add
> > > > > > > > > >> > > > that to thin clients.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > Thin client protocol provides a way to create a
> > cache
> > > > with
> > > > > > > > custom
> > > > > > > > > >> > config
> > > > > > > > > >> > > > [1].
> > > > > > > > > >> > > > It is up to thin client library authors to use any
> > > > config
> > > > > > > format
> > > > > > > > > they
> > > > > > > > > >> > > like
> > > > > > > > > >> > > > and then convert it into protocol-defined format.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > C# thin client uses custom format, for example,
> not
> > > > > Spring.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > [1]
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > https://apacheignite.readme.
> io/docs/binary-client-
> > > > > > > > > >> > > protocol-cache-configuration-
> > > operations#section-op_cache_
> > > > > > > > > >> > > create_with_configuration
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > On Mon, May 14, 2018 at 7:54 PM, Ivan Rakov <
> > > > > > > > > ivan.glukos@gmail.com>
> > > > > > > > > >> > > wrote:
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > > Dmitry,
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > > We rely on Spring Framework when we start Ignite
> > > node
> > > > > from
> > > > > > > XML
> > > > > > > > > >> > > > > configuration. Spring doesn't easily support
> > another
> > > > > > formats
> > > > > > > > of
> > > > > > > > > >> > > > > configuration files. I think, the main reason
> for
> > > this
> > > > > is
> > > > > > > > > built-in
> > > > > > > > > >> > > > ability
> > > > > > > > > >> > > > > to validate configuration via XML Schema. We can
> > > > surely
> > > > > > hack
> > > > > > > > > this
> > > > > > > > > >> > > around
> > > > > > > > > >> > > > (I
> > > > > > > > > >> > > > > bet there are existing libraries for configuring
> > > > Spring
> > > > > > with
> > > > > > > > > JSON),
> > > > > > > > > >> > > but I
> > > > > > > > > >> > > > > don't think that anyone suffered from inability
> to
> > > > > > > statically
> > > > > > > > > >> > configure
> > > > > > > > > >> > > > > Ignite with json/yaml.
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > > Regarding thin clients: makes sense. I suppose
> > > > necessary
> > > > > > > > > mappings
> > > > > > > > > >> > will
> > > > > > > > > >> > > be
> > > > > > > > > >> > > > > implemented as a part of thin client.
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > > Best Regards,
> > > > > > > > > >> > > > > Ivan Rakov
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > > On 14.05.2018 18:58, Dmitriy Govorukhin wrote:
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > >> Hi, Igniters!
> > > > > > > > > >> > > > >>
> > > > > > > > > >> > > > >> As far as I know, many people work on a thin
> > client
> > > > for
> > > > > > > > > different
> > > > > > > > > >> > > > language
> > > > > > > > > >> > > > >> (go,js,php...).
> > > > > > > > > >> > > > >> Are there any reasons why ignite does not
> support
> > > > yaml
> > > > > or
> > > > > > > > json
> > > > > > > > > >> > format
> > > > > > > > > >> > > > for
> > > > > > > > > >> > > > >> configuration? or some other popular format?
> > > > > > > > > >> > > > >> In future, it can help to integrate with thin
> > > > clients,
> > > > > > for
> > > > > > > > > >> example,
> > > > > > > > > >> > js
> > > > > > > > > >> > > > >> client may want to dynamic cache start, he
> passes
> > > > cache
> > > > > > > > > >> > configuration
> > > > > > > > > >> > > > (in
> > > > > > > > > >> > > > >> native format, for js it will json) through
> TCP,
> > > > Ignite
> > > > > > > node
> > > > > > > > > >> unwrap
> > > > > > > > > >> > > and
> > > > > > > > > >> > > > >> remap to java representation and dynamic start
> > > cache.
> > > > > > > > > >> > > > >>
> > > > > > > > > >> > > > >>
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > >
> > > > > > > > > >> > >
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Best regards,
> >   Andrey Kuznetsov.
> >
>

Re: supporting different configuration format json,yaml...

Posted by Andrey Gura <ag...@apache.org>.

Guys,

Spring is IoC and you can't offer any format that can  replace Spring. It
will just limited DSL.

Once again. We have enough problems with main functionality. Why do you
want to focus on minor features?


вт, 15 мая 2018 г., 23:26 Andrey Kuznetsov <st...@gmail.com>:

> Pavel,
>
> One can use json-schema if necessary. Of course, XML is more powerful in
> many aspects, but produces more eye fatigue for humans. Of course, we are
> to stay with XML if switching to another configuration format requires
> significant effort.
>
> BTW, first time I heard about JSON from [1] : " JSON is like XML, except it
> doesn't suck ".
>
> [1] https://github.com/cajun-jsonapi/cajun-jsonapi/blob/master/Readme.txt
>
>
> 2018-05-15 22:43 GMT+03:00 Pavel Tupitsyn <pt...@apache.org>:
>
> > JSON sucks for config files anyway, there are no comments, no schemas,
> > quotes are required around keys, etc
> >
> > Just answer one question: what issue are we trying to solve?
> > XML is not a problem IMO, complexity of our config is.
> >
> > On Tue, May 15, 2018 at 8:00 PM, Igor Sapego <is...@apache.org> wrote:
> >
> > > How are you going to translate this YAML config to Spring config?
> > >
> > > How would you deal with something like [1]?
> > >
> > > [1] -
> > > https://github.com/apache/ignite/blob/master/modules/
> > > platforms/cpp/odbc-test/config/queries-ssl-32.xml
> > >
> > > Best Regards,
> > > Igor
> > >
> > > On Tue, May 15, 2018 at 7:10 PM, Pavel Kovalenko <jo...@gmail.com>
> > > wrote:
> > >
> > > > Igor,
> > > >
> > > > Just get one of the config samples and translate it directly to YAML:
> > > > XML - https://pastebin.com/wtQXXq8f
> > > > YAML - https://pastebin.com/akGu3e81
> > > >
> > > > 2018-05-15 18:49 GMT+03:00 Igor Sapego <is...@apache.org>:
> > > >
> > > > > Guys, if you think the YAML or JSON would be better, how about
> > > > > you provide us a brief example of how such configs are going to
> > > > > look, so we can compare and see, if this ever have any sense.
> > > > >
> > > > > Best Regards,
> > > > > Igor
> > > > >
> > > > > On Tue, May 15, 2018 at 4:20 PM, Ilya Kasnacheev <
> > > > > ilya.kasnacheev@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hello!
> > > > > >
> > > > > > Maybe we should take .Net configuration as a standard, extend it
> to
> > > > JSON
> > > > > > and YAML?
> > > > > >
> > > > > > <goog_787531833>
> > > > > > https://apacheignite-net.readme.io/docs/configuration
> > > > > >
> > > > > > It should be fairly robust, and there's much less boilerplate.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Ilya Kasnacheev
> > > > > >
> > > > > > 2018-05-15 16:09 GMT+03:00 Pavel Kovalenko <jo...@gmail.com>:
> > > > > >
> > > > > > > +1 to Dmitriy G. proposal.
> > > > > > >
> > > > > > > Since we're moving Ignite towards outside of Java world, we
> > should
> > > > > > > definitely care about config usability for users who are not
> > > familiar
> > > > > > with
> > > > > > > Java/Spring.
> > > > > > > If we take a look at any of our XML-configs, we can see a lot
> of
> > > > > > > boilerplate like "<bean class="">", "<property name="">" -
> terms
> > > > which
> > > > > > say
> > > > > > > nothing to users outside of Java world.
> > > > > > > When I see such configs my eyes are filled with bloody tears.
> > > > > > >
> > > > > > > I think we should really consider YAML as our additional
> approach
> > > to
> > > > > > > configure Ignite with full replacement instead of XML in
> future.
> > > > > > > Comparing to XML, YAML is significantly more human-readable and
> > > > > > lightweight
> > > > > > > format and has stable Java library to parse and translate
> config
> > > > files
> > > > > to
> > > > > > > Java objects without extra-magic.
> > > > > > >
> > > > > > > We can find a lot of famous projects which are using YAML:
> Apache
> > > > > Flink,
> > > > > > > Apache Storm/Heron and one of the our main rivals - Apache
> > > Cassandra.
> > > > > > >
> > > > > > > Some of the projects use simple <property>=<name> config form
> > > (Kafka,
> > > > > > > Spark), some of the projects use their own YAML-like format
> > > > (Aerospike,
> > > > > > > Tarantool), but it's really difficult to find such project
> which
> > > has
> > > > so
> > > > > > > heavy config as us (maybe VoltDB).
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 2018-05-15 14:02 GMT+03:00 Andrey Gura <ag...@apache.org>:
> > > > > > >
> > > > > > > > Actually sometimes users ask about JSON configuration (e.g.
> was
> > > PR
> > > > in
> > > > > > > > vertx-ignite project). But it's non trivial task because it
> > will
> > > > > > > > require development of some DSL (or set of DSL's) and will
> make
> > > > > adding
> > > > > > > > new configuration elements some kind of pain while we should
> be
> > > > > > > > focused on basic functionality: data grid, persistence, etc.
> > > > > > > >
> > > > > > > > I just believe that configuration format is not so important
> > > aspect
> > > > > > > > and this task is out of product scope.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Tue, May 15, 2018 at 12:56 PM, Dmitriy Setrakyan
> > > > > > > > <ds...@apache.org> wrote:
> > > > > > > > > I still do not understand *why* do we need to add
> additional
> > > > > formats
> > > > > > > for
> > > > > > > > > the configuration. Can you please show me some users on the
> > > user@
> > > > > > list
> > > > > > > > or
> > > > > > > > > stack overflow who asked for it? I just want to make sure
> > that
> > > if
> > > > > we
> > > > > > > are
> > > > > > > > > creating work for ourselves, then someone actually needs
> it.
> > > > > > > > >
> > > > > > > > > D.
> > > > > > > > >
> > > > > > > > > On Tue, May 15, 2018 at 12:41 PM, Igor Sapego <
> > > > isapego@apache.org>
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > >> I don't think we need to add new formats on server side as
> > > there
> > > > > may
> > > > > > > > >> be a lot of different formats for different clients. On
> the
> > > > other
> > > > > > > hand,
> > > > > > > > >> supporting additional formats may be non trivial and
> > > > error-prone,
> > > > > > > while
> > > > > > > > >> adding little to a user experience.
> > > > > > > > >>
> > > > > > > > >> For clients, I see no problem in adding for example JSON
> ->
> > > XML
> > > > > > > > >> converter on client side, if JS folks need it.
> > > > > > > > >>
> > > > > > > > >> For servers, adding another configuration format just to
> > make
> > > it
> > > > > > more
> > > > > > > > >> familiar to users with no Java background seems
> unreasonable
> > > to
> > > > me
> > > > > > > > >> as well, as there still going to be Java class names in
> > > > > > configuration
> > > > > > > > >> and Spring approach in general.
> > > > > > > > >>
> > > > > > > > >> What will change is a XML formatting is going to change to
> > > JSON
> > > > > > > > >> formatting, which has no much sense to me, as everyone
> know
> > > XML.
> > > > > > > > >> It is Spring approach what can be confusing to non-Java
> > users,
> > > > and
> > > > > > > > >> it is not going to change regardless of format.
> > > > > > > > >>
> > > > > > > > >> Best Regards,
> > > > > > > > >> Igor
> > > > > > > > >>
> > > > > > > > >> On Tue, May 15, 2018 at 12:15 PM, Dmitriy Govorukhin <
> > > > > > > > >> dmitriy.govorukhin@gmail.com> wrote:
> > > > > > > > >>
> > > > > > > > >> > Folks,
> > > > > > > > >> >
> > > > > > > > >> > I guess when work on a thin client will be completed, we
> > get
> > > > > more
> > > > > > > > >> newcomers
> > > > > > > > >> > who use go/python/php/js.
> > > > > > > > >> > And we can do ignite more friendly for them, support
> > > familiar
> > > > > > > formats
> > > > > > > > for
> > > > > > > > >> > configuration.
> > > > > > > > >> >
> > > > > > > > >> > On Tue, May 15, 2018 at 12:13 PM, Dmitry Pavlov <
> > > > > > > > dpavlov.spb@gmail.com>
> > > > > > > > >> > wrote:
> > > > > > > > >> >
> > > > > > > > >> > > Hi Igniters,
> > > > > > > > >> > >
> > > > > > > > >> > > In general I aggree with adding new format, e.g. JSON
> is
> > > > more
> > > > > > > > popular
> > > > > > > > >> > than
> > > > > > > > >> > > XML for new applications.
> > > > > > > > >> > >
> > > > > > > > >> > > In the same time I've never heard that user asked this
> > in
> > > > the
> > > > > > user
> > > > > > > > >> list.
> > > > > > > > >> > Or
> > > > > > > > >> > > did I missed such topics?
> > > > > > > > >> > >
> > > > > > > > >> > > Sincerely,
> > > > > > > > >> > > Dmitriy Pavlov
> > > > > > > > >> > >
> > > > > > > > >> > > вт, 15 мая 2018 г. в 9:31, Pavel Tupitsyn <
> > > > > ptupitsyn@apache.org
> > > > > > >:
> > > > > > > > >> > >
> > > > > > > > >> > > > Dmitriy,
> > > > > > > > >> > > >
> > > > > > > > >> > > > We don't need to support different config formats on
> > > > server
> > > > > in
> > > > > > > > order
> > > > > > > > >> to
> > > > > > > > >> > > add
> > > > > > > > >> > > > that to thin clients.
> > > > > > > > >> > > >
> > > > > > > > >> > > > Thin client protocol provides a way to create a
> cache
> > > with
> > > > > > > custom
> > > > > > > > >> > config
> > > > > > > > >> > > > [1].
> > > > > > > > >> > > > It is up to thin client library authors to use any
> > > config
> > > > > > format
> > > > > > > > they
> > > > > > > > >> > > like
> > > > > > > > >> > > > and then convert it into protocol-defined format.
> > > > > > > > >> > > >
> > > > > > > > >> > > > C# thin client uses custom format, for example, not
> > > > Spring.
> > > > > > > > >> > > >
> > > > > > > > >> > > > [1]
> > > > > > > > >> > > >
> > > > > > > > >> > > > https://apacheignite.readme.io/docs/binary-client-
> > > > > > > > >> > > protocol-cache-configuration-
> > operations#section-op_cache_
> > > > > > > > >> > > create_with_configuration
> > > > > > > > >> > > >
> > > > > > > > >> > > > On Mon, May 14, 2018 at 7:54 PM, Ivan Rakov <
> > > > > > > > ivan.glukos@gmail.com>
> > > > > > > > >> > > wrote:
> > > > > > > > >> > > >
> > > > > > > > >> > > > > Dmitry,
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > We rely on Spring Framework when we start Ignite
> > node
> > > > from
> > > > > > XML
> > > > > > > > >> > > > > configuration. Spring doesn't easily support
> another
> > > > > formats
> > > > > > > of
> > > > > > > > >> > > > > configuration files. I think, the main reason for
> > this
> > > > is
> > > > > > > > built-in
> > > > > > > > >> > > > ability
> > > > > > > > >> > > > > to validate configuration via XML Schema. We can
> > > surely
> > > > > hack
> > > > > > > > this
> > > > > > > > >> > > around
> > > > > > > > >> > > > (I
> > > > > > > > >> > > > > bet there are existing libraries for configuring
> > > Spring
> > > > > with
> > > > > > > > JSON),
> > > > > > > > >> > > but I
> > > > > > > > >> > > > > don't think that anyone suffered from inability to
> > > > > > statically
> > > > > > > > >> > configure
> > > > > > > > >> > > > > Ignite with json/yaml.
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > Regarding thin clients: makes sense. I suppose
> > > necessary
> > > > > > > > mappings
> > > > > > > > >> > will
> > > > > > > > >> > > be
> > > > > > > > >> > > > > implemented as a part of thin client.
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > Best Regards,
> > > > > > > > >> > > > > Ivan Rakov
> > > > > > > > >> > > > >
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > On 14.05.2018 18:58, Dmitriy Govorukhin wrote:
> > > > > > > > >> > > > >
> > > > > > > > >> > > > >> Hi, Igniters!
> > > > > > > > >> > > > >>
> > > > > > > > >> > > > >> As far as I know, many people work on a thin
> client
> > > for
> > > > > > > > different
> > > > > > > > >> > > > language
> > > > > > > > >> > > > >> (go,js,php...).
> > > > > > > > >> > > > >> Are there any reasons why ignite does not support
> > > yaml
> > > > or
> > > > > > > json
> > > > > > > > >> > format
> > > > > > > > >> > > > for
> > > > > > > > >> > > > >> configuration? or some other popular format?
> > > > > > > > >> > > > >> In future, it can help to integrate with thin
> > > clients,
> > > > > for
> > > > > > > > >> example,
> > > > > > > > >> > js
> > > > > > > > >> > > > >> client may want to dynamic cache start, he passes
> > > cache
> > > > > > > > >> > configuration
> > > > > > > > >> > > > (in
> > > > > > > > >> > > > >> native format, for js it will json) through TCP,
> > > Ignite
> > > > > > node
> > > > > > > > >> unwrap
> > > > > > > > >> > > and
> > > > > > > > >> > > > >> remap to java representation and dynamic start
> > cache.
> > > > > > > > >> > > > >>
> > > > > > > > >> > > > >>
> > > > > > > > >> > > > >
> > > > > > > > >> > > >
> > > > > > > > >> > >
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
>
> --
> Best regards,
>   Andrey Kuznetsov.
>

Re: supporting different configuration format json,yaml...

Posted by Andrey Kuznetsov <st...@gmail.com>.

Pavel,

One can use json-schema if necessary. Of course, XML is more powerful in
many aspects, but produces more eye fatigue for humans. Of course, we are
to stay with XML if switching to another configuration format requires
significant effort.

BTW, first time I heard about JSON from [1] : " JSON is like XML, except it
doesn't suck ".

[1] https://github.com/cajun-jsonapi/cajun-jsonapi/blob/master/Readme.txt


2018-05-15 22:43 GMT+03:00 Pavel Tupitsyn <pt...@apache.org>:

> JSON sucks for config files anyway, there are no comments, no schemas,
> quotes are required around keys, etc
>
> Just answer one question: what issue are we trying to solve?
> XML is not a problem IMO, complexity of our config is.
>
> On Tue, May 15, 2018 at 8:00 PM, Igor Sapego <is...@apache.org> wrote:
>
> > How are you going to translate this YAML config to Spring config?
> >
> > How would you deal with something like [1]?
> >
> > [1] -
> > https://github.com/apache/ignite/blob/master/modules/
> > platforms/cpp/odbc-test/config/queries-ssl-32.xml
> >
> > Best Regards,
> > Igor
> >
> > On Tue, May 15, 2018 at 7:10 PM, Pavel Kovalenko <jo...@gmail.com>
> > wrote:
> >
> > > Igor,
> > >
> > > Just get one of the config samples and translate it directly to YAML:
> > > XML - https://pastebin.com/wtQXXq8f
> > > YAML - https://pastebin.com/akGu3e81
> > >
> > > 2018-05-15 18:49 GMT+03:00 Igor Sapego <is...@apache.org>:
> > >
> > > > Guys, if you think the YAML or JSON would be better, how about
> > > > you provide us a brief example of how such configs are going to
> > > > look, so we can compare and see, if this ever have any sense.
> > > >
> > > > Best Regards,
> > > > Igor
> > > >
> > > > On Tue, May 15, 2018 at 4:20 PM, Ilya Kasnacheev <
> > > > ilya.kasnacheev@gmail.com>
> > > > wrote:
> > > >
> > > > > Hello!
> > > > >
> > > > > Maybe we should take .Net configuration as a standard, extend it to
> > > JSON
> > > > > and YAML?
> > > > >
> > > > > <goog_787531833>
> > > > > https://apacheignite-net.readme.io/docs/configuration
> > > > >
> > > > > It should be fairly robust, and there's much less boilerplate.
> > > > >
> > > > > Regards,
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Ilya Kasnacheev
> > > > >
> > > > > 2018-05-15 16:09 GMT+03:00 Pavel Kovalenko <jo...@gmail.com>:
> > > > >
> > > > > > +1 to Dmitriy G. proposal.
> > > > > >
> > > > > > Since we're moving Ignite towards outside of Java world, we
> should
> > > > > > definitely care about config usability for users who are not
> > familiar
> > > > > with
> > > > > > Java/Spring.
> > > > > > If we take a look at any of our XML-configs, we can see a lot of
> > > > > > boilerplate like "<bean class="">", "<property name="">" - terms
> > > which
> > > > > say
> > > > > > nothing to users outside of Java world.
> > > > > > When I see such configs my eyes are filled with bloody tears.
> > > > > >
> > > > > > I think we should really consider YAML as our additional approach
> > to
> > > > > > configure Ignite with full replacement instead of XML in future.
> > > > > > Comparing to XML, YAML is significantly more human-readable and
> > > > > lightweight
> > > > > > format and has stable Java library to parse and translate config
> > > files
> > > > to
> > > > > > Java objects without extra-magic.
> > > > > >
> > > > > > We can find a lot of famous projects which are using YAML: Apache
> > > > Flink,
> > > > > > Apache Storm/Heron and one of the our main rivals - Apache
> > Cassandra.
> > > > > >
> > > > > > Some of the projects use simple <property>=<name> config form
> > (Kafka,
> > > > > > Spark), some of the projects use their own YAML-like format
> > > (Aerospike,
> > > > > > Tarantool), but it's really difficult to find such project which
> > has
> > > so
> > > > > > heavy config as us (maybe VoltDB).
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2018-05-15 14:02 GMT+03:00 Andrey Gura <ag...@apache.org>:
> > > > > >
> > > > > > > Actually sometimes users ask about JSON configuration (e.g. was
> > PR
> > > in
> > > > > > > vertx-ignite project). But it's non trivial task because it
> will
> > > > > > > require development of some DSL (or set of DSL's) and will make
> > > > adding
> > > > > > > new configuration elements some kind of pain while we should be
> > > > > > > focused on basic functionality: data grid, persistence, etc.
> > > > > > >
> > > > > > > I just believe that configuration format is not so important
> > aspect
> > > > > > > and this task is out of product scope.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Tue, May 15, 2018 at 12:56 PM, Dmitriy Setrakyan
> > > > > > > <ds...@apache.org> wrote:
> > > > > > > > I still do not understand *why* do we need to add additional
> > > > formats
> > > > > > for
> > > > > > > > the configuration. Can you please show me some users on the
> > user@
> > > > > list
> > > > > > > or
> > > > > > > > stack overflow who asked for it? I just want to make sure
> that
> > if
> > > > we
> > > > > > are
> > > > > > > > creating work for ourselves, then someone actually needs it.
> > > > > > > >
> > > > > > > > D.
> > > > > > > >
> > > > > > > > On Tue, May 15, 2018 at 12:41 PM, Igor Sapego <
> > > isapego@apache.org>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > >> I don't think we need to add new formats on server side as
> > there
> > > > may
> > > > > > > >> be a lot of different formats for different clients. On the
> > > other
> > > > > > hand,
> > > > > > > >> supporting additional formats may be non trivial and
> > > error-prone,
> > > > > > while
> > > > > > > >> adding little to a user experience.
> > > > > > > >>
> > > > > > > >> For clients, I see no problem in adding for example JSON ->
> > XML
> > > > > > > >> converter on client side, if JS folks need it.
> > > > > > > >>
> > > > > > > >> For servers, adding another configuration format just to
> make
> > it
> > > > > more
> > > > > > > >> familiar to users with no Java background seems unreasonable
> > to
> > > me
> > > > > > > >> as well, as there still going to be Java class names in
> > > > > configuration
> > > > > > > >> and Spring approach in general.
> > > > > > > >>
> > > > > > > >> What will change is a XML formatting is going to change to
> > JSON
> > > > > > > >> formatting, which has no much sense to me, as everyone know
> > XML.
> > > > > > > >> It is Spring approach what can be confusing to non-Java
> users,
> > > and
> > > > > > > >> it is not going to change regardless of format.
> > > > > > > >>
> > > > > > > >> Best Regards,
> > > > > > > >> Igor
> > > > > > > >>
> > > > > > > >> On Tue, May 15, 2018 at 12:15 PM, Dmitriy Govorukhin <
> > > > > > > >> dmitriy.govorukhin@gmail.com> wrote:
> > > > > > > >>
> > > > > > > >> > Folks,
> > > > > > > >> >
> > > > > > > >> > I guess when work on a thin client will be completed, we
> get
> > > > more
> > > > > > > >> newcomers
> > > > > > > >> > who use go/python/php/js.
> > > > > > > >> > And we can do ignite more friendly for them, support
> > familiar
> > > > > > formats
> > > > > > > for
> > > > > > > >> > configuration.
> > > > > > > >> >
> > > > > > > >> > On Tue, May 15, 2018 at 12:13 PM, Dmitry Pavlov <
> > > > > > > dpavlov.spb@gmail.com>
> > > > > > > >> > wrote:
> > > > > > > >> >
> > > > > > > >> > > Hi Igniters,
> > > > > > > >> > >
> > > > > > > >> > > In general I aggree with adding new format, e.g. JSON is
> > > more
> > > > > > > popular
> > > > > > > >> > than
> > > > > > > >> > > XML for new applications.
> > > > > > > >> > >
> > > > > > > >> > > In the same time I've never heard that user asked this
> in
> > > the
> > > > > user
> > > > > > > >> list.
> > > > > > > >> > Or
> > > > > > > >> > > did I missed such topics?
> > > > > > > >> > >
> > > > > > > >> > > Sincerely,
> > > > > > > >> > > Dmitriy Pavlov
> > > > > > > >> > >
> > > > > > > >> > > вт, 15 мая 2018 г. в 9:31, Pavel Tupitsyn <
> > > > ptupitsyn@apache.org
> > > > > >:
> > > > > > > >> > >
> > > > > > > >> > > > Dmitriy,
> > > > > > > >> > > >
> > > > > > > >> > > > We don't need to support different config formats on
> > > server
> > > > in
> > > > > > > order
> > > > > > > >> to
> > > > > > > >> > > add
> > > > > > > >> > > > that to thin clients.
> > > > > > > >> > > >
> > > > > > > >> > > > Thin client protocol provides a way to create a cache
> > with
> > > > > > custom
> > > > > > > >> > config
> > > > > > > >> > > > [1].
> > > > > > > >> > > > It is up to thin client library authors to use any
> > config
> > > > > format
> > > > > > > they
> > > > > > > >> > > like
> > > > > > > >> > > > and then convert it into protocol-defined format.
> > > > > > > >> > > >
> > > > > > > >> > > > C# thin client uses custom format, for example, not
> > > Spring.
> > > > > > > >> > > >
> > > > > > > >> > > > [1]
> > > > > > > >> > > >
> > > > > > > >> > > > https://apacheignite.readme.io/docs/binary-client-
> > > > > > > >> > > protocol-cache-configuration-
> operations#section-op_cache_
> > > > > > > >> > > create_with_configuration
> > > > > > > >> > > >
> > > > > > > >> > > > On Mon, May 14, 2018 at 7:54 PM, Ivan Rakov <
> > > > > > > ivan.glukos@gmail.com>
> > > > > > > >> > > wrote:
> > > > > > > >> > > >
> > > > > > > >> > > > > Dmitry,
> > > > > > > >> > > > >
> > > > > > > >> > > > > We rely on Spring Framework when we start Ignite
> node
> > > from
> > > > > XML
> > > > > > > >> > > > > configuration. Spring doesn't easily support another
> > > > formats
> > > > > > of
> > > > > > > >> > > > > configuration files. I think, the main reason for
> this
> > > is
> > > > > > > built-in
> > > > > > > >> > > > ability
> > > > > > > >> > > > > to validate configuration via XML Schema. We can
> > surely
> > > > hack
> > > > > > > this
> > > > > > > >> > > around
> > > > > > > >> > > > (I
> > > > > > > >> > > > > bet there are existing libraries for configuring
> > Spring
> > > > with
> > > > > > > JSON),
> > > > > > > >> > > but I
> > > > > > > >> > > > > don't think that anyone suffered from inability to
> > > > > statically
> > > > > > > >> > configure
> > > > > > > >> > > > > Ignite with json/yaml.
> > > > > > > >> > > > >
> > > > > > > >> > > > > Regarding thin clients: makes sense. I suppose
> > necessary
> > > > > > > mappings
> > > > > > > >> > will
> > > > > > > >> > > be
> > > > > > > >> > > > > implemented as a part of thin client.
> > > > > > > >> > > > >
> > > > > > > >> > > > > Best Regards,
> > > > > > > >> > > > > Ivan Rakov
> > > > > > > >> > > > >
> > > > > > > >> > > > >
> > > > > > > >> > > > > On 14.05.2018 18:58, Dmitriy Govorukhin wrote:
> > > > > > > >> > > > >
> > > > > > > >> > > > >> Hi, Igniters!
> > > > > > > >> > > > >>
> > > > > > > >> > > > >> As far as I know, many people work on a thin client
> > for
> > > > > > > different
> > > > > > > >> > > > language
> > > > > > > >> > > > >> (go,js,php...).
> > > > > > > >> > > > >> Are there any reasons why ignite does not support
> > yaml
> > > or
> > > > > > json
> > > > > > > >> > format
> > > > > > > >> > > > for
> > > > > > > >> > > > >> configuration? or some other popular format?
> > > > > > > >> > > > >> In future, it can help to integrate with thin
> > clients,
> > > > for
> > > > > > > >> example,
> > > > > > > >> > js
> > > > > > > >> > > > >> client may want to dynamic cache start, he passes
> > cache
> > > > > > > >> > configuration
> > > > > > > >> > > > (in
> > > > > > > >> > > > >> native format, for js it will json) through TCP,
> > Ignite
> > > > > node
> > > > > > > >> unwrap
> > > > > > > >> > > and
> > > > > > > >> > > > >> remap to java representation and dynamic start
> cache.
> > > > > > > >> > > > >>
> > > > > > > >> > > > >>
> > > > > > > >> > > > >
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>



-- 
Best regards,
  Andrey Kuznetsov.

Re: supporting different configuration format json,yaml...

Posted by Pavel Tupitsyn <pt...@apache.org>.

JSON sucks for config files anyway, there are no comments, no schemas,
quotes are required around keys, etc

Just answer one question: what issue are we trying to solve?
XML is not a problem IMO, complexity of our config is.

On Tue, May 15, 2018 at 8:00 PM, Igor Sapego <is...@apache.org> wrote:

> How are you going to translate this YAML config to Spring config?
>
> How would you deal with something like [1]?
>
> [1] -
> https://github.com/apache/ignite/blob/master/modules/
> platforms/cpp/odbc-test/config/queries-ssl-32.xml
>
> Best Regards,
> Igor
>
> On Tue, May 15, 2018 at 7:10 PM, Pavel Kovalenko <jo...@gmail.com>
> wrote:
>
> > Igor,
> >
> > Just get one of the config samples and translate it directly to YAML:
> > XML - https://pastebin.com/wtQXXq8f
> > YAML - https://pastebin.com/akGu3e81
> >
> > 2018-05-15 18:49 GMT+03:00 Igor Sapego <is...@apache.org>:
> >
> > > Guys, if you think the YAML or JSON would be better, how about
> > > you provide us a brief example of how such configs are going to
> > > look, so we can compare and see, if this ever have any sense.
> > >
> > > Best Regards,
> > > Igor
> > >
> > > On Tue, May 15, 2018 at 4:20 PM, Ilya Kasnacheev <
> > > ilya.kasnacheev@gmail.com>
> > > wrote:
> > >
> > > > Hello!
> > > >
> > > > Maybe we should take .Net configuration as a standard, extend it to
> > JSON
> > > > and YAML?
> > > >
> > > > <goog_787531833>
> > > > https://apacheignite-net.readme.io/docs/configuration
> > > >
> > > > It should be fairly robust, and there's much less boilerplate.
> > > >
> > > > Regards,
> > > >
> > > >
> > > >
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > > 2018-05-15 16:09 GMT+03:00 Pavel Kovalenko <jo...@gmail.com>:
> > > >
> > > > > +1 to Dmitriy G. proposal.
> > > > >
> > > > > Since we're moving Ignite towards outside of Java world, we should
> > > > > definitely care about config usability for users who are not
> familiar
> > > > with
> > > > > Java/Spring.
> > > > > If we take a look at any of our XML-configs, we can see a lot of
> > > > > boilerplate like "<bean class="">", "<property name="">" - terms
> > which
> > > > say
> > > > > nothing to users outside of Java world.
> > > > > When I see such configs my eyes are filled with bloody tears.
> > > > >
> > > > > I think we should really consider YAML as our additional approach
> to
> > > > > configure Ignite with full replacement instead of XML in future.
> > > > > Comparing to XML, YAML is significantly more human-readable and
> > > > lightweight
> > > > > format and has stable Java library to parse and translate config
> > files
> > > to
> > > > > Java objects without extra-magic.
> > > > >
> > > > > We can find a lot of famous projects which are using YAML: Apache
> > > Flink,
> > > > > Apache Storm/Heron and one of the our main rivals - Apache
> Cassandra.
> > > > >
> > > > > Some of the projects use simple <property>=<name> config form
> (Kafka,
> > > > > Spark), some of the projects use their own YAML-like format
> > (Aerospike,
> > > > > Tarantool), but it's really difficult to find such project which
> has
> > so
> > > > > heavy config as us (maybe VoltDB).
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 2018-05-15 14:02 GMT+03:00 Andrey Gura <ag...@apache.org>:
> > > > >
> > > > > > Actually sometimes users ask about JSON configuration (e.g. was
> PR
> > in
> > > > > > vertx-ignite project). But it's non trivial task because it will
> > > > > > require development of some DSL (or set of DSL's) and will make
> > > adding
> > > > > > new configuration elements some kind of pain while we should be
> > > > > > focused on basic functionality: data grid, persistence, etc.
> > > > > >
> > > > > > I just believe that configuration format is not so important
> aspect
> > > > > > and this task is out of product scope.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, May 15, 2018 at 12:56 PM, Dmitriy Setrakyan
> > > > > > <ds...@apache.org> wrote:
> > > > > > > I still do not understand *why* do we need to add additional
> > > formats
> > > > > for
> > > > > > > the configuration. Can you please show me some users on the
> user@
> > > > list
> > > > > > or
> > > > > > > stack overflow who asked for it? I just want to make sure that
> if
> > > we
> > > > > are
> > > > > > > creating work for ourselves, then someone actually needs it.
> > > > > > >
> > > > > > > D.
> > > > > > >
> > > > > > > On Tue, May 15, 2018 at 12:41 PM, Igor Sapego <
> > isapego@apache.org>
> > > > > > wrote:
> > > > > > >
> > > > > > >> I don't think we need to add new formats on server side as
> there
> > > may
> > > > > > >> be a lot of different formats for different clients. On the
> > other
> > > > > hand,
> > > > > > >> supporting additional formats may be non trivial and
> > error-prone,
> > > > > while
> > > > > > >> adding little to a user experience.
> > > > > > >>
> > > > > > >> For clients, I see no problem in adding for example JSON ->
> XML
> > > > > > >> converter on client side, if JS folks need it.
> > > > > > >>
> > > > > > >> For servers, adding another configuration format just to make
> it
> > > > more
> > > > > > >> familiar to users with no Java background seems unreasonable
> to
> > me
> > > > > > >> as well, as there still going to be Java class names in
> > > > configuration
> > > > > > >> and Spring approach in general.
> > > > > > >>
> > > > > > >> What will change is a XML formatting is going to change to
> JSON
> > > > > > >> formatting, which has no much sense to me, as everyone know
> XML.
> > > > > > >> It is Spring approach what can be confusing to non-Java users,
> > and
> > > > > > >> it is not going to change regardless of format.
> > > > > > >>
> > > > > > >> Best Regards,
> > > > > > >> Igor
> > > > > > >>
> > > > > > >> On Tue, May 15, 2018 at 12:15 PM, Dmitriy Govorukhin <
> > > > > > >> dmitriy.govorukhin@gmail.com> wrote:
> > > > > > >>
> > > > > > >> > Folks,
> > > > > > >> >
> > > > > > >> > I guess when work on a thin client will be completed, we get
> > > more
> > > > > > >> newcomers
> > > > > > >> > who use go/python/php/js.
> > > > > > >> > And we can do ignite more friendly for them, support
> familiar
> > > > > formats
> > > > > > for
> > > > > > >> > configuration.
> > > > > > >> >
> > > > > > >> > On Tue, May 15, 2018 at 12:13 PM, Dmitry Pavlov <
> > > > > > dpavlov.spb@gmail.com>
> > > > > > >> > wrote:
> > > > > > >> >
> > > > > > >> > > Hi Igniters,
> > > > > > >> > >
> > > > > > >> > > In general I aggree with adding new format, e.g. JSON is
> > more
> > > > > > popular
> > > > > > >> > than
> > > > > > >> > > XML for new applications.
> > > > > > >> > >
> > > > > > >> > > In the same time I've never heard that user asked this in
> > the
> > > > user
> > > > > > >> list.
> > > > > > >> > Or
> > > > > > >> > > did I missed such topics?
> > > > > > >> > >
> > > > > > >> > > Sincerely,
> > > > > > >> > > Dmitriy Pavlov
> > > > > > >> > >
> > > > > > >> > > вт, 15 мая 2018 г. в 9:31, Pavel Tupitsyn <
> > > ptupitsyn@apache.org
> > > > >:
> > > > > > >> > >
> > > > > > >> > > > Dmitriy,
> > > > > > >> > > >
> > > > > > >> > > > We don't need to support different config formats on
> > server
> > > in
> > > > > > order
> > > > > > >> to
> > > > > > >> > > add
> > > > > > >> > > > that to thin clients.
> > > > > > >> > > >
> > > > > > >> > > > Thin client protocol provides a way to create a cache
> with
> > > > > custom
> > > > > > >> > config
> > > > > > >> > > > [1].
> > > > > > >> > > > It is up to thin client library authors to use any
> config
> > > > format
> > > > > > they
> > > > > > >> > > like
> > > > > > >> > > > and then convert it into protocol-defined format.
> > > > > > >> > > >
> > > > > > >> > > > C# thin client uses custom format, for example, not
> > Spring.
> > > > > > >> > > >
> > > > > > >> > > > [1]
> > > > > > >> > > >
> > > > > > >> > > > https://apacheignite.readme.io/docs/binary-client-
> > > > > > >> > > protocol-cache-configuration-operations#section-op_cache_
> > > > > > >> > > create_with_configuration
> > > > > > >> > > >
> > > > > > >> > > > On Mon, May 14, 2018 at 7:54 PM, Ivan Rakov <
> > > > > > ivan.glukos@gmail.com>
> > > > > > >> > > wrote:
> > > > > > >> > > >
> > > > > > >> > > > > Dmitry,
> > > > > > >> > > > >
> > > > > > >> > > > > We rely on Spring Framework when we start Ignite node
> > from
> > > > XML
> > > > > > >> > > > > configuration. Spring doesn't easily support another
> > > formats
> > > > > of
> > > > > > >> > > > > configuration files. I think, the main reason for this
> > is
> > > > > > built-in
> > > > > > >> > > > ability
> > > > > > >> > > > > to validate configuration via XML Schema. We can
> surely
> > > hack
> > > > > > this
> > > > > > >> > > around
> > > > > > >> > > > (I
> > > > > > >> > > > > bet there are existing libraries for configuring
> Spring
> > > with
> > > > > > JSON),
> > > > > > >> > > but I
> > > > > > >> > > > > don't think that anyone suffered from inability to
> > > > statically
> > > > > > >> > configure
> > > > > > >> > > > > Ignite with json/yaml.
> > > > > > >> > > > >
> > > > > > >> > > > > Regarding thin clients: makes sense. I suppose
> necessary
> > > > > > mappings
> > > > > > >> > will
> > > > > > >> > > be
> > > > > > >> > > > > implemented as a part of thin client.
> > > > > > >> > > > >
> > > > > > >> > > > > Best Regards,
> > > > > > >> > > > > Ivan Rakov
> > > > > > >> > > > >
> > > > > > >> > > > >
> > > > > > >> > > > > On 14.05.2018 18:58, Dmitriy Govorukhin wrote:
> > > > > > >> > > > >
> > > > > > >> > > > >> Hi, Igniters!
> > > > > > >> > > > >>
> > > > > > >> > > > >> As far as I know, many people work on a thin client
> for
> > > > > > different
> > > > > > >> > > > language
> > > > > > >> > > > >> (go,js,php...).
> > > > > > >> > > > >> Are there any reasons why ignite does not support
> yaml
> > or
> > > > > json
> > > > > > >> > format
> > > > > > >> > > > for
> > > > > > >> > > > >> configuration? or some other popular format?
> > > > > > >> > > > >> In future, it can help to integrate with thin
> clients,
> > > for
> > > > > > >> example,
> > > > > > >> > js
> > > > > > >> > > > >> client may want to dynamic cache start, he passes
> cache
> > > > > > >> > configuration
> > > > > > >> > > > (in
> > > > > > >> > > > >> native format, for js it will json) through TCP,
> Ignite
> > > > node
> > > > > > >> unwrap
> > > > > > >> > > and
> > > > > > >> > > > >> remap to java representation and dynamic start cache.
> > > > > > >> > > > >>
> > > > > > >> > > > >>
> > > > > > >> > > > >
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: supporting different configuration format json,yaml...

Posted by Igor Sapego <is...@apache.org>.

How are you going to translate this YAML config to Spring config?

How would you deal with something like [1]?

[1] -
https://github.com/apache/ignite/blob/master/modules/platforms/cpp/odbc-test/config/queries-ssl-32.xml

Best Regards,
Igor

On Tue, May 15, 2018 at 7:10 PM, Pavel Kovalenko <jo...@gmail.com> wrote:

> Igor,
>
> Just get one of the config samples and translate it directly to YAML:
> XML - https://pastebin.com/wtQXXq8f
> YAML - https://pastebin.com/akGu3e81
>
> 2018-05-15 18:49 GMT+03:00 Igor Sapego <is...@apache.org>:
>
> > Guys, if you think the YAML or JSON would be better, how about
> > you provide us a brief example of how such configs are going to
> > look, so we can compare and see, if this ever have any sense.
> >
> > Best Regards,
> > Igor
> >
> > On Tue, May 15, 2018 at 4:20 PM, Ilya Kasnacheev <
> > ilya.kasnacheev@gmail.com>
> > wrote:
> >
> > > Hello!
> > >
> > > Maybe we should take .Net configuration as a standard, extend it to
> JSON
> > > and YAML?
> > >
> > > <goog_787531833>
> > > https://apacheignite-net.readme.io/docs/configuration
> > >
> > > It should be fairly robust, and there's much less boilerplate.
> > >
> > > Regards,
> > >
> > >
> > >
> > > --
> > > Ilya Kasnacheev
> > >
> > > 2018-05-15 16:09 GMT+03:00 Pavel Kovalenko <jo...@gmail.com>:
> > >
> > > > +1 to Dmitriy G. proposal.
> > > >
> > > > Since we're moving Ignite towards outside of Java world, we should
> > > > definitely care about config usability for users who are not familiar
> > > with
> > > > Java/Spring.
> > > > If we take a look at any of our XML-configs, we can see a lot of
> > > > boilerplate like "<bean class="">", "<property name="">" - terms
> which
> > > say
> > > > nothing to users outside of Java world.
> > > > When I see such configs my eyes are filled with bloody tears.
> > > >
> > > > I think we should really consider YAML as our additional approach to
> > > > configure Ignite with full replacement instead of XML in future.
> > > > Comparing to XML, YAML is significantly more human-readable and
> > > lightweight
> > > > format and has stable Java library to parse and translate config
> files
> > to
> > > > Java objects without extra-magic.
> > > >
> > > > We can find a lot of famous projects which are using YAML: Apache
> > Flink,
> > > > Apache Storm/Heron and one of the our main rivals - Apache Cassandra.
> > > >
> > > > Some of the projects use simple <property>=<name> config form (Kafka,
> > > > Spark), some of the projects use their own YAML-like format
> (Aerospike,
> > > > Tarantool), but it's really difficult to find such project which has
> so
> > > > heavy config as us (maybe VoltDB).
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > 2018-05-15 14:02 GMT+03:00 Andrey Gura <ag...@apache.org>:
> > > >
> > > > > Actually sometimes users ask about JSON configuration (e.g. was PR
> in
> > > > > vertx-ignite project). But it's non trivial task because it will
> > > > > require development of some DSL (or set of DSL's) and will make
> > adding
> > > > > new configuration elements some kind of pain while we should be
> > > > > focused on basic functionality: data grid, persistence, etc.
> > > > >
> > > > > I just believe that configuration format is not so important aspect
> > > > > and this task is out of product scope.
> > > > >
> > > > >
> > > > >
> > > > > On Tue, May 15, 2018 at 12:56 PM, Dmitriy Setrakyan
> > > > > <ds...@apache.org> wrote:
> > > > > > I still do not understand *why* do we need to add additional
> > formats
> > > > for
> > > > > > the configuration. Can you please show me some users on the user@
> > > list
> > > > > or
> > > > > > stack overflow who asked for it? I just want to make sure that if
> > we
> > > > are
> > > > > > creating work for ourselves, then someone actually needs it.
> > > > > >
> > > > > > D.
> > > > > >
> > > > > > On Tue, May 15, 2018 at 12:41 PM, Igor Sapego <
> isapego@apache.org>
> > > > > wrote:
> > > > > >
> > > > > >> I don't think we need to add new formats on server side as there
> > may
> > > > > >> be a lot of different formats for different clients. On the
> other
> > > > hand,
> > > > > >> supporting additional formats may be non trivial and
> error-prone,
> > > > while
> > > > > >> adding little to a user experience.
> > > > > >>
> > > > > >> For clients, I see no problem in adding for example JSON -> XML
> > > > > >> converter on client side, if JS folks need it.
> > > > > >>
> > > > > >> For servers, adding another configuration format just to make it
> > > more
> > > > > >> familiar to users with no Java background seems unreasonable to
> me
> > > > > >> as well, as there still going to be Java class names in
> > > configuration
> > > > > >> and Spring approach in general.
> > > > > >>
> > > > > >> What will change is a XML formatting is going to change to JSON
> > > > > >> formatting, which has no much sense to me, as everyone know XML.
> > > > > >> It is Spring approach what can be confusing to non-Java users,
> and
> > > > > >> it is not going to change regardless of format.
> > > > > >>
> > > > > >> Best Regards,
> > > > > >> Igor
> > > > > >>
> > > > > >> On Tue, May 15, 2018 at 12:15 PM, Dmitriy Govorukhin <
> > > > > >> dmitriy.govorukhin@gmail.com> wrote:
> > > > > >>
> > > > > >> > Folks,
> > > > > >> >
> > > > > >> > I guess when work on a thin client will be completed, we get
> > more
> > > > > >> newcomers
> > > > > >> > who use go/python/php/js.
> > > > > >> > And we can do ignite more friendly for them, support familiar
> > > > formats
> > > > > for
> > > > > >> > configuration.
> > > > > >> >
> > > > > >> > On Tue, May 15, 2018 at 12:13 PM, Dmitry Pavlov <
> > > > > dpavlov.spb@gmail.com>
> > > > > >> > wrote:
> > > > > >> >
> > > > > >> > > Hi Igniters,
> > > > > >> > >
> > > > > >> > > In general I aggree with adding new format, e.g. JSON is
> more
> > > > > popular
> > > > > >> > than
> > > > > >> > > XML for new applications.
> > > > > >> > >
> > > > > >> > > In the same time I've never heard that user asked this in
> the
> > > user
> > > > > >> list.
> > > > > >> > Or
> > > > > >> > > did I missed such topics?
> > > > > >> > >
> > > > > >> > > Sincerely,
> > > > > >> > > Dmitriy Pavlov
> > > > > >> > >
> > > > > >> > > вт, 15 мая 2018 г. в 9:31, Pavel Tupitsyn <
> > ptupitsyn@apache.org
> > > >:
> > > > > >> > >
> > > > > >> > > > Dmitriy,
> > > > > >> > > >
> > > > > >> > > > We don't need to support different config formats on
> server
> > in
> > > > > order
> > > > > >> to
> > > > > >> > > add
> > > > > >> > > > that to thin clients.
> > > > > >> > > >
> > > > > >> > > > Thin client protocol provides a way to create a cache with
> > > > custom
> > > > > >> > config
> > > > > >> > > > [1].
> > > > > >> > > > It is up to thin client library authors to use any config
> > > format
> > > > > they
> > > > > >> > > like
> > > > > >> > > > and then convert it into protocol-defined format.
> > > > > >> > > >
> > > > > >> > > > C# thin client uses custom format, for example, not
> Spring.
> > > > > >> > > >
> > > > > >> > > > [1]
> > > > > >> > > >
> > > > > >> > > > https://apacheignite.readme.io/docs/binary-client-
> > > > > >> > > protocol-cache-configuration-operations#section-op_cache_
> > > > > >> > > create_with_configuration
> > > > > >> > > >
> > > > > >> > > > On Mon, May 14, 2018 at 7:54 PM, Ivan Rakov <
> > > > > ivan.glukos@gmail.com>
> > > > > >> > > wrote:
> > > > > >> > > >
> > > > > >> > > > > Dmitry,
> > > > > >> > > > >
> > > > > >> > > > > We rely on Spring Framework when we start Ignite node
> from
> > > XML
> > > > > >> > > > > configuration. Spring doesn't easily support another
> > formats
> > > > of
> > > > > >> > > > > configuration files. I think, the main reason for this
> is
> > > > > built-in
> > > > > >> > > > ability
> > > > > >> > > > > to validate configuration via XML Schema. We can surely
> > hack
> > > > > this
> > > > > >> > > around
> > > > > >> > > > (I
> > > > > >> > > > > bet there are existing libraries for configuring Spring
> > with
> > > > > JSON),
> > > > > >> > > but I
> > > > > >> > > > > don't think that anyone suffered from inability to
> > > statically
> > > > > >> > configure
> > > > > >> > > > > Ignite with json/yaml.
> > > > > >> > > > >
> > > > > >> > > > > Regarding thin clients: makes sense. I suppose necessary
> > > > > mappings
> > > > > >> > will
> > > > > >> > > be
> > > > > >> > > > > implemented as a part of thin client.
> > > > > >> > > > >
> > > > > >> > > > > Best Regards,
> > > > > >> > > > > Ivan Rakov
> > > > > >> > > > >
> > > > > >> > > > >
> > > > > >> > > > > On 14.05.2018 18:58, Dmitriy Govorukhin wrote:
> > > > > >> > > > >
> > > > > >> > > > >> Hi, Igniters!
> > > > > >> > > > >>
> > > > > >> > > > >> As far as I know, many people work on a thin client for
> > > > > different
> > > > > >> > > > language
> > > > > >> > > > >> (go,js,php...).
> > > > > >> > > > >> Are there any reasons why ignite does not support yaml
> or
> > > > json
> > > > > >> > format
> > > > > >> > > > for
> > > > > >> > > > >> configuration? or some other popular format?
> > > > > >> > > > >> In future, it can help to integrate with thin clients,
> > for
> > > > > >> example,
> > > > > >> > js
> > > > > >> > > > >> client may want to dynamic cache start, he passes cache
> > > > > >> > configuration
> > > > > >> > > > (in
> > > > > >> > > > >> native format, for js it will json) through TCP, Ignite
> > > node
> > > > > >> unwrap
> > > > > >> > > and
> > > > > >> > > > >> remap to java representation and dynamic start cache.
> > > > > >> > > > >>
> > > > > >> > > > >>
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
>

Re: supporting different configuration format json,yaml...

Posted by Pavel Kovalenko <jo...@gmail.com>.

Igor,

Just get one of the config samples and translate it directly to YAML:
XML - https://pastebin.com/wtQXXq8f
YAML - https://pastebin.com/akGu3e81

2018-05-15 18:49 GMT+03:00 Igor Sapego <is...@apache.org>:

> Guys, if you think the YAML or JSON would be better, how about
> you provide us a brief example of how such configs are going to
> look, so we can compare and see, if this ever have any sense.
>
> Best Regards,
> Igor
>
> On Tue, May 15, 2018 at 4:20 PM, Ilya Kasnacheev <
> ilya.kasnacheev@gmail.com>
> wrote:
>
> > Hello!
> >
> > Maybe we should take .Net configuration as a standard, extend it to JSON
> > and YAML?
> >
> > <goog_787531833>
> > https://apacheignite-net.readme.io/docs/configuration
> >
> > It should be fairly robust, and there's much less boilerplate.
> >
> > Regards,
> >
> >
> >
> > --
> > Ilya Kasnacheev
> >
> > 2018-05-15 16:09 GMT+03:00 Pavel Kovalenko <jo...@gmail.com>:
> >
> > > +1 to Dmitriy G. proposal.
> > >
> > > Since we're moving Ignite towards outside of Java world, we should
> > > definitely care about config usability for users who are not familiar
> > with
> > > Java/Spring.
> > > If we take a look at any of our XML-configs, we can see a lot of
> > > boilerplate like "<bean class="">", "<property name="">" - terms which
> > say
> > > nothing to users outside of Java world.
> > > When I see such configs my eyes are filled with bloody tears.
> > >
> > > I think we should really consider YAML as our additional approach to
> > > configure Ignite with full replacement instead of XML in future.
> > > Comparing to XML, YAML is significantly more human-readable and
> > lightweight
> > > format and has stable Java library to parse and translate config files
> to
> > > Java objects without extra-magic.
> > >
> > > We can find a lot of famous projects which are using YAML: Apache
> Flink,
> > > Apache Storm/Heron and one of the our main rivals - Apache Cassandra.
> > >
> > > Some of the projects use simple <property>=<name> config form (Kafka,
> > > Spark), some of the projects use their own YAML-like format (Aerospike,
> > > Tarantool), but it's really difficult to find such project which has so
> > > heavy config as us (maybe VoltDB).
> > >
> > >
> > >
> > >
> > >
> > >
> > > 2018-05-15 14:02 GMT+03:00 Andrey Gura <ag...@apache.org>:
> > >
> > > > Actually sometimes users ask about JSON configuration (e.g. was PR in
> > > > vertx-ignite project). But it's non trivial task because it will
> > > > require development of some DSL (or set of DSL's) and will make
> adding
> > > > new configuration elements some kind of pain while we should be
> > > > focused on basic functionality: data grid, persistence, etc.
> > > >
> > > > I just believe that configuration format is not so important aspect
> > > > and this task is out of product scope.
> > > >
> > > >
> > > >
> > > > On Tue, May 15, 2018 at 12:56 PM, Dmitriy Setrakyan
> > > > <ds...@apache.org> wrote:
> > > > > I still do not understand *why* do we need to add additional
> formats
> > > for
> > > > > the configuration. Can you please show me some users on the user@
> > list
> > > > or
> > > > > stack overflow who asked for it? I just want to make sure that if
> we
> > > are
> > > > > creating work for ourselves, then someone actually needs it.
> > > > >
> > > > > D.
> > > > >
> > > > > On Tue, May 15, 2018 at 12:41 PM, Igor Sapego <is...@apache.org>
> > > > wrote:
> > > > >
> > > > >> I don't think we need to add new formats on server side as there
> may
> > > > >> be a lot of different formats for different clients. On the other
> > > hand,
> > > > >> supporting additional formats may be non trivial and error-prone,
> > > while
> > > > >> adding little to a user experience.
> > > > >>
> > > > >> For clients, I see no problem in adding for example JSON -> XML
> > > > >> converter on client side, if JS folks need it.
> > > > >>
> > > > >> For servers, adding another configuration format just to make it
> > more
> > > > >> familiar to users with no Java background seems unreasonable to me
> > > > >> as well, as there still going to be Java class names in
> > configuration
> > > > >> and Spring approach in general.
> > > > >>
> > > > >> What will change is a XML formatting is going to change to JSON
> > > > >> formatting, which has no much sense to me, as everyone know XML.
> > > > >> It is Spring approach what can be confusing to non-Java users, and
> > > > >> it is not going to change regardless of format.
> > > > >>
> > > > >> Best Regards,
> > > > >> Igor
> > > > >>
> > > > >> On Tue, May 15, 2018 at 12:15 PM, Dmitriy Govorukhin <
> > > > >> dmitriy.govorukhin@gmail.com> wrote:
> > > > >>
> > > > >> > Folks,
> > > > >> >
> > > > >> > I guess when work on a thin client will be completed, we get
> more
> > > > >> newcomers
> > > > >> > who use go/python/php/js.
> > > > >> > And we can do ignite more friendly for them, support familiar
> > > formats
> > > > for
> > > > >> > configuration.
> > > > >> >
> > > > >> > On Tue, May 15, 2018 at 12:13 PM, Dmitry Pavlov <
> > > > dpavlov.spb@gmail.com>
> > > > >> > wrote:
> > > > >> >
> > > > >> > > Hi Igniters,
> > > > >> > >
> > > > >> > > In general I aggree with adding new format, e.g. JSON is more
> > > > popular
> > > > >> > than
> > > > >> > > XML for new applications.
> > > > >> > >
> > > > >> > > In the same time I've never heard that user asked this in the
> > user
> > > > >> list.
> > > > >> > Or
> > > > >> > > did I missed such topics?
> > > > >> > >
> > > > >> > > Sincerely,
> > > > >> > > Dmitriy Pavlov
> > > > >> > >
> > > > >> > > вт, 15 мая 2018 г. в 9:31, Pavel Tupitsyn <
> ptupitsyn@apache.org
> > >:
> > > > >> > >
> > > > >> > > > Dmitriy,
> > > > >> > > >
> > > > >> > > > We don't need to support different config formats on server
> in
> > > > order
> > > > >> to
> > > > >> > > add
> > > > >> > > > that to thin clients.
> > > > >> > > >
> > > > >> > > > Thin client protocol provides a way to create a cache with
> > > custom
> > > > >> > config
> > > > >> > > > [1].
> > > > >> > > > It is up to thin client library authors to use any config
> > format
> > > > they
> > > > >> > > like
> > > > >> > > > and then convert it into protocol-defined format.
> > > > >> > > >
> > > > >> > > > C# thin client uses custom format, for example, not Spring.
> > > > >> > > >
> > > > >> > > > [1]
> > > > >> > > >
> > > > >> > > > https://apacheignite.readme.io/docs/binary-client-
> > > > >> > > protocol-cache-configuration-operations#section-op_cache_
> > > > >> > > create_with_configuration
> > > > >> > > >
> > > > >> > > > On Mon, May 14, 2018 at 7:54 PM, Ivan Rakov <
> > > > ivan.glukos@gmail.com>
> > > > >> > > wrote:
> > > > >> > > >
> > > > >> > > > > Dmitry,
> > > > >> > > > >
> > > > >> > > > > We rely on Spring Framework when we start Ignite node from
> > XML
> > > > >> > > > > configuration. Spring doesn't easily support another
> formats
> > > of
> > > > >> > > > > configuration files. I think, the main reason for this is
> > > > built-in
> > > > >> > > > ability
> > > > >> > > > > to validate configuration via XML Schema. We can surely
> hack
> > > > this
> > > > >> > > around
> > > > >> > > > (I
> > > > >> > > > > bet there are existing libraries for configuring Spring
> with
> > > > JSON),
> > > > >> > > but I
> > > > >> > > > > don't think that anyone suffered from inability to
> > statically
> > > > >> > configure
> > > > >> > > > > Ignite with json/yaml.
> > > > >> > > > >
> > > > >> > > > > Regarding thin clients: makes sense. I suppose necessary
> > > > mappings
> > > > >> > will
> > > > >> > > be
> > > > >> > > > > implemented as a part of thin client.
> > > > >> > > > >
> > > > >> > > > > Best Regards,
> > > > >> > > > > Ivan Rakov
> > > > >> > > > >
> > > > >> > > > >
> > > > >> > > > > On 14.05.2018 18:58, Dmitriy Govorukhin wrote:
> > > > >> > > > >
> > > > >> > > > >> Hi, Igniters!
> > > > >> > > > >>
> > > > >> > > > >> As far as I know, many people work on a thin client for
> > > > different
> > > > >> > > > language
> > > > >> > > > >> (go,js,php...).
> > > > >> > > > >> Are there any reasons why ignite does not support yaml or
> > > json
> > > > >> > format
> > > > >> > > > for
> > > > >> > > > >> configuration? or some other popular format?
> > > > >> > > > >> In future, it can help to integrate with thin clients,
> for
> > > > >> example,
> > > > >> > js
> > > > >> > > > >> client may want to dynamic cache start, he passes cache
> > > > >> > configuration
> > > > >> > > > (in
> > > > >> > > > >> native format, for js it will json) through TCP, Ignite
> > node
> > > > >> unwrap
> > > > >> > > and
> > > > >> > > > >> remap to java representation and dynamic start cache.
> > > > >> > > > >>
> > > > >> > > > >>
> > > > >> > > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
>

Re: supporting different configuration format json,yaml...

Posted by Igor Sapego <is...@apache.org>.

Guys, if you think the YAML or JSON would be better, how about
you provide us a brief example of how such configs are going to
look, so we can compare and see, if this ever have any sense.

Best Regards,
Igor

On Tue, May 15, 2018 at 4:20 PM, Ilya Kasnacheev <il...@gmail.com>
wrote:

> Hello!
>
> Maybe we should take .Net configuration as a standard, extend it to JSON
> and YAML?
>
> <goog_787531833>
> https://apacheignite-net.readme.io/docs/configuration
>
> It should be fairly robust, and there's much less boilerplate.
>
> Regards,
>
>
>
> --
> Ilya Kasnacheev
>
> 2018-05-15 16:09 GMT+03:00 Pavel Kovalenko <jo...@gmail.com>:
>
> > +1 to Dmitriy G. proposal.
> >
> > Since we're moving Ignite towards outside of Java world, we should
> > definitely care about config usability for users who are not familiar
> with
> > Java/Spring.
> > If we take a look at any of our XML-configs, we can see a lot of
> > boilerplate like "<bean class="">", "<property name="">" - terms which
> say
> > nothing to users outside of Java world.
> > When I see such configs my eyes are filled with bloody tears.
> >
> > I think we should really consider YAML as our additional approach to
> > configure Ignite with full replacement instead of XML in future.
> > Comparing to XML, YAML is significantly more human-readable and
> lightweight
> > format and has stable Java library to parse and translate config files to
> > Java objects without extra-magic.
> >
> > We can find a lot of famous projects which are using YAML: Apache Flink,
> > Apache Storm/Heron and one of the our main rivals - Apache Cassandra.
> >
> > Some of the projects use simple <property>=<name> config form (Kafka,
> > Spark), some of the projects use their own YAML-like format (Aerospike,
> > Tarantool), but it's really difficult to find such project which has so
> > heavy config as us (maybe VoltDB).
> >
> >
> >
> >
> >
> >
> > 2018-05-15 14:02 GMT+03:00 Andrey Gura <ag...@apache.org>:
> >
> > > Actually sometimes users ask about JSON configuration (e.g. was PR in
> > > vertx-ignite project). But it's non trivial task because it will
> > > require development of some DSL (or set of DSL's) and will make adding
> > > new configuration elements some kind of pain while we should be
> > > focused on basic functionality: data grid, persistence, etc.
> > >
> > > I just believe that configuration format is not so important aspect
> > > and this task is out of product scope.
> > >
> > >
> > >
> > > On Tue, May 15, 2018 at 12:56 PM, Dmitriy Setrakyan
> > > <ds...@apache.org> wrote:
> > > > I still do not understand *why* do we need to add additional formats
> > for
> > > > the configuration. Can you please show me some users on the user@
> list
> > > or
> > > > stack overflow who asked for it? I just want to make sure that if we
> > are
> > > > creating work for ourselves, then someone actually needs it.
> > > >
> > > > D.
> > > >
> > > > On Tue, May 15, 2018 at 12:41 PM, Igor Sapego <is...@apache.org>
> > > wrote:
> > > >
> > > >> I don't think we need to add new formats on server side as there may
> > > >> be a lot of different formats for different clients. On the other
> > hand,
> > > >> supporting additional formats may be non trivial and error-prone,
> > while
> > > >> adding little to a user experience.
> > > >>
> > > >> For clients, I see no problem in adding for example JSON -> XML
> > > >> converter on client side, if JS folks need it.
> > > >>
> > > >> For servers, adding another configuration format just to make it
> more
> > > >> familiar to users with no Java background seems unreasonable to me
> > > >> as well, as there still going to be Java class names in
> configuration
> > > >> and Spring approach in general.
> > > >>
> > > >> What will change is a XML formatting is going to change to JSON
> > > >> formatting, which has no much sense to me, as everyone know XML.
> > > >> It is Spring approach what can be confusing to non-Java users, and
> > > >> it is not going to change regardless of format.
> > > >>
> > > >> Best Regards,
> > > >> Igor
> > > >>
> > > >> On Tue, May 15, 2018 at 12:15 PM, Dmitriy Govorukhin <
> > > >> dmitriy.govorukhin@gmail.com> wrote:
> > > >>
> > > >> > Folks,
> > > >> >
> > > >> > I guess when work on a thin client will be completed, we get more
> > > >> newcomers
> > > >> > who use go/python/php/js.
> > > >> > And we can do ignite more friendly for them, support familiar
> > formats
> > > for
> > > >> > configuration.
> > > >> >
> > > >> > On Tue, May 15, 2018 at 12:13 PM, Dmitry Pavlov <
> > > dpavlov.spb@gmail.com>
> > > >> > wrote:
> > > >> >
> > > >> > > Hi Igniters,
> > > >> > >
> > > >> > > In general I aggree with adding new format, e.g. JSON is more
> > > popular
> > > >> > than
> > > >> > > XML for new applications.
> > > >> > >
> > > >> > > In the same time I've never heard that user asked this in the
> user
> > > >> list.
> > > >> > Or
> > > >> > > did I missed such topics?
> > > >> > >
> > > >> > > Sincerely,
> > > >> > > Dmitriy Pavlov
> > > >> > >
> > > >> > > вт, 15 мая 2018 г. в 9:31, Pavel Tupitsyn <ptupitsyn@apache.org
> >:
> > > >> > >
> > > >> > > > Dmitriy,
> > > >> > > >
> > > >> > > > We don't need to support different config formats on server in
> > > order
> > > >> to
> > > >> > > add
> > > >> > > > that to thin clients.
> > > >> > > >
> > > >> > > > Thin client protocol provides a way to create a cache with
> > custom
> > > >> > config
> > > >> > > > [1].
> > > >> > > > It is up to thin client library authors to use any config
> format
> > > they
> > > >> > > like
> > > >> > > > and then convert it into protocol-defined format.
> > > >> > > >
> > > >> > > > C# thin client uses custom format, for example, not Spring.
> > > >> > > >
> > > >> > > > [1]
> > > >> > > >
> > > >> > > > https://apacheignite.readme.io/docs/binary-client-
> > > >> > > protocol-cache-configuration-operations#section-op_cache_
> > > >> > > create_with_configuration
> > > >> > > >
> > > >> > > > On Mon, May 14, 2018 at 7:54 PM, Ivan Rakov <
> > > ivan.glukos@gmail.com>
> > > >> > > wrote:
> > > >> > > >
> > > >> > > > > Dmitry,
> > > >> > > > >
> > > >> > > > > We rely on Spring Framework when we start Ignite node from
> XML
> > > >> > > > > configuration. Spring doesn't easily support another formats
> > of
> > > >> > > > > configuration files. I think, the main reason for this is
> > > built-in
> > > >> > > > ability
> > > >> > > > > to validate configuration via XML Schema. We can surely hack
> > > this
> > > >> > > around
> > > >> > > > (I
> > > >> > > > > bet there are existing libraries for configuring Spring with
> > > JSON),
> > > >> > > but I
> > > >> > > > > don't think that anyone suffered from inability to
> statically
> > > >> > configure
> > > >> > > > > Ignite with json/yaml.
> > > >> > > > >
> > > >> > > > > Regarding thin clients: makes sense. I suppose necessary
> > > mappings
> > > >> > will
> > > >> > > be
> > > >> > > > > implemented as a part of thin client.
> > > >> > > > >
> > > >> > > > > Best Regards,
> > > >> > > > > Ivan Rakov
> > > >> > > > >
> > > >> > > > >
> > > >> > > > > On 14.05.2018 18:58, Dmitriy Govorukhin wrote:
> > > >> > > > >
> > > >> > > > >> Hi, Igniters!
> > > >> > > > >>
> > > >> > > > >> As far as I know, many people work on a thin client for
> > > different
> > > >> > > > language
> > > >> > > > >> (go,js,php...).
> > > >> > > > >> Are there any reasons why ignite does not support yaml or
> > json
> > > >> > format
> > > >> > > > for
> > > >> > > > >> configuration? or some other popular format?
> > > >> > > > >> In future, it can help to integrate with thin clients, for
> > > >> example,
> > > >> > js
> > > >> > > > >> client may want to dynamic cache start, he passes cache
> > > >> > configuration
> > > >> > > > (in
> > > >> > > > >> native format, for js it will json) through TCP, Ignite
> node
> > > >> unwrap
> > > >> > > and
> > > >> > > > >> remap to java representation and dynamic start cache.
> > > >> > > > >>
> > > >> > > > >>
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
>

Re: supporting different configuration format json,yaml...

Posted by Ilya Kasnacheev <il...@gmail.com>.

Hello!

Maybe we should take .Net configuration as a standard, extend it to JSON
and YAML?

<goog_787531833>
https://apacheignite-net.readme.io/docs/configuration

It should be fairly robust, and there's much less boilerplate.

Regards,



-- 
Ilya Kasnacheev

2018-05-15 16:09 GMT+03:00 Pavel Kovalenko <jo...@gmail.com>:

> +1 to Dmitriy G. proposal.
>
> Since we're moving Ignite towards outside of Java world, we should
> definitely care about config usability for users who are not familiar with
> Java/Spring.
> If we take a look at any of our XML-configs, we can see a lot of
> boilerplate like "<bean class="">", "<property name="">" - terms which say
> nothing to users outside of Java world.
> When I see such configs my eyes are filled with bloody tears.
>
> I think we should really consider YAML as our additional approach to
> configure Ignite with full replacement instead of XML in future.
> Comparing to XML, YAML is significantly more human-readable and lightweight
> format and has stable Java library to parse and translate config files to
> Java objects without extra-magic.
>
> We can find a lot of famous projects which are using YAML: Apache Flink,
> Apache Storm/Heron and one of the our main rivals - Apache Cassandra.
>
> Some of the projects use simple <property>=<name> config form (Kafka,
> Spark), some of the projects use their own YAML-like format (Aerospike,
> Tarantool), but it's really difficult to find such project which has so
> heavy config as us (maybe VoltDB).
>
>
>
>
>
>
> 2018-05-15 14:02 GMT+03:00 Andrey Gura <ag...@apache.org>:
>
> > Actually sometimes users ask about JSON configuration (e.g. was PR in
> > vertx-ignite project). But it's non trivial task because it will
> > require development of some DSL (or set of DSL's) and will make adding
> > new configuration elements some kind of pain while we should be
> > focused on basic functionality: data grid, persistence, etc.
> >
> > I just believe that configuration format is not so important aspect
> > and this task is out of product scope.
> >
> >
> >
> > On Tue, May 15, 2018 at 12:56 PM, Dmitriy Setrakyan
> > <ds...@apache.org> wrote:
> > > I still do not understand *why* do we need to add additional formats
> for
> > > the configuration. Can you please show me some users on the user@ list
> > or
> > > stack overflow who asked for it? I just want to make sure that if we
> are
> > > creating work for ourselves, then someone actually needs it.
> > >
> > > D.
> > >
> > > On Tue, May 15, 2018 at 12:41 PM, Igor Sapego <is...@apache.org>
> > wrote:
> > >
> > >> I don't think we need to add new formats on server side as there may
> > >> be a lot of different formats for different clients. On the other
> hand,
> > >> supporting additional formats may be non trivial and error-prone,
> while
> > >> adding little to a user experience.
> > >>
> > >> For clients, I see no problem in adding for example JSON -> XML
> > >> converter on client side, if JS folks need it.
> > >>
> > >> For servers, adding another configuration format just to make it more
> > >> familiar to users with no Java background seems unreasonable to me
> > >> as well, as there still going to be Java class names in configuration
> > >> and Spring approach in general.
> > >>
> > >> What will change is a XML formatting is going to change to JSON
> > >> formatting, which has no much sense to me, as everyone know XML.
> > >> It is Spring approach what can be confusing to non-Java users, and
> > >> it is not going to change regardless of format.
> > >>
> > >> Best Regards,
> > >> Igor
> > >>
> > >> On Tue, May 15, 2018 at 12:15 PM, Dmitriy Govorukhin <
> > >> dmitriy.govorukhin@gmail.com> wrote:
> > >>
> > >> > Folks,
> > >> >
> > >> > I guess when work on a thin client will be completed, we get more
> > >> newcomers
> > >> > who use go/python/php/js.
> > >> > And we can do ignite more friendly for them, support familiar
> formats
> > for
> > >> > configuration.
> > >> >
> > >> > On Tue, May 15, 2018 at 12:13 PM, Dmitry Pavlov <
> > dpavlov.spb@gmail.com>
> > >> > wrote:
> > >> >
> > >> > > Hi Igniters,
> > >> > >
> > >> > > In general I aggree with adding new format, e.g. JSON is more
> > popular
> > >> > than
> > >> > > XML for new applications.
> > >> > >
> > >> > > In the same time I've never heard that user asked this in the user
> > >> list.
> > >> > Or
> > >> > > did I missed such topics?
> > >> > >
> > >> > > Sincerely,
> > >> > > Dmitriy Pavlov
> > >> > >
> > >> > > вт, 15 мая 2018 г. в 9:31, Pavel Tupitsyn <pt...@apache.org>:
> > >> > >
> > >> > > > Dmitriy,
> > >> > > >
> > >> > > > We don't need to support different config formats on server in
> > order
> > >> to
> > >> > > add
> > >> > > > that to thin clients.
> > >> > > >
> > >> > > > Thin client protocol provides a way to create a cache with
> custom
> > >> > config
> > >> > > > [1].
> > >> > > > It is up to thin client library authors to use any config format
> > they
> > >> > > like
> > >> > > > and then convert it into protocol-defined format.
> > >> > > >
> > >> > > > C# thin client uses custom format, for example, not Spring.
> > >> > > >
> > >> > > > [1]
> > >> > > >
> > >> > > > https://apacheignite.readme.io/docs/binary-client-
> > >> > > protocol-cache-configuration-operations#section-op_cache_
> > >> > > create_with_configuration
> > >> > > >
> > >> > > > On Mon, May 14, 2018 at 7:54 PM, Ivan Rakov <
> > ivan.glukos@gmail.com>
> > >> > > wrote:
> > >> > > >
> > >> > > > > Dmitry,
> > >> > > > >
> > >> > > > > We rely on Spring Framework when we start Ignite node from XML
> > >> > > > > configuration. Spring doesn't easily support another formats
> of
> > >> > > > > configuration files. I think, the main reason for this is
> > built-in
> > >> > > > ability
> > >> > > > > to validate configuration via XML Schema. We can surely hack
> > this
> > >> > > around
> > >> > > > (I
> > >> > > > > bet there are existing libraries for configuring Spring with
> > JSON),
> > >> > > but I
> > >> > > > > don't think that anyone suffered from inability to statically
> > >> > configure
> > >> > > > > Ignite with json/yaml.
> > >> > > > >
> > >> > > > > Regarding thin clients: makes sense. I suppose necessary
> > mappings
> > >> > will
> > >> > > be
> > >> > > > > implemented as a part of thin client.
> > >> > > > >
> > >> > > > > Best Regards,
> > >> > > > > Ivan Rakov
> > >> > > > >
> > >> > > > >
> > >> > > > > On 14.05.2018 18:58, Dmitriy Govorukhin wrote:
> > >> > > > >
> > >> > > > >> Hi, Igniters!
> > >> > > > >>
> > >> > > > >> As far as I know, many people work on a thin client for
> > different
> > >> > > > language
> > >> > > > >> (go,js,php...).
> > >> > > > >> Are there any reasons why ignite does not support yaml or
> json
> > >> > format
> > >> > > > for
> > >> > > > >> configuration? or some other popular format?
> > >> > > > >> In future, it can help to integrate with thin clients, for
> > >> example,
> > >> > js
> > >> > > > >> client may want to dynamic cache start, he passes cache
> > >> > configuration
> > >> > > > (in
> > >> > > > >> native format, for js it will json) through TCP, Ignite node
> > >> unwrap
> > >> > > and
> > >> > > > >> remap to java representation and dynamic start cache.
> > >> > > > >>
> > >> > > > >>
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
>

Re: supporting different configuration format json,yaml...

Posted by Pavel Kovalenko <jo...@gmail.com>.

+1 to Dmitriy G. proposal.

Since we're moving Ignite towards outside of Java world, we should
definitely care about config usability for users who are not familiar with
Java/Spring.
If we take a look at any of our XML-configs, we can see a lot of
boilerplate like "<bean class="">", "<property name="">" - terms which say
nothing to users outside of Java world.
When I see such configs my eyes are filled with bloody tears.

I think we should really consider YAML as our additional approach to
configure Ignite with full replacement instead of XML in future.
Comparing to XML, YAML is significantly more human-readable and lightweight
format and has stable Java library to parse and translate config files to
Java objects without extra-magic.

We can find a lot of famous projects which are using YAML: Apache Flink,
Apache Storm/Heron and one of the our main rivals - Apache Cassandra.

Some of the projects use simple <property>=<name> config form (Kafka,
Spark), some of the projects use their own YAML-like format (Aerospike,
Tarantool), but it's really difficult to find such project which has so
heavy config as us (maybe VoltDB).






2018-05-15 14:02 GMT+03:00 Andrey Gura <ag...@apache.org>:

> Actually sometimes users ask about JSON configuration (e.g. was PR in
> vertx-ignite project). But it's non trivial task because it will
> require development of some DSL (or set of DSL's) and will make adding
> new configuration elements some kind of pain while we should be
> focused on basic functionality: data grid, persistence, etc.
>
> I just believe that configuration format is not so important aspect
> and this task is out of product scope.
>
>
>
> On Tue, May 15, 2018 at 12:56 PM, Dmitriy Setrakyan
> <ds...@apache.org> wrote:
> > I still do not understand *why* do we need to add additional formats for
> > the configuration. Can you please show me some users on the user@ list
> or
> > stack overflow who asked for it? I just want to make sure that if we are
> > creating work for ourselves, then someone actually needs it.
> >
> > D.
> >
> > On Tue, May 15, 2018 at 12:41 PM, Igor Sapego <is...@apache.org>
> wrote:
> >
> >> I don't think we need to add new formats on server side as there may
> >> be a lot of different formats for different clients. On the other hand,
> >> supporting additional formats may be non trivial and error-prone, while
> >> adding little to a user experience.
> >>
> >> For clients, I see no problem in adding for example JSON -> XML
> >> converter on client side, if JS folks need it.
> >>
> >> For servers, adding another configuration format just to make it more
> >> familiar to users with no Java background seems unreasonable to me
> >> as well, as there still going to be Java class names in configuration
> >> and Spring approach in general.
> >>
> >> What will change is a XML formatting is going to change to JSON
> >> formatting, which has no much sense to me, as everyone know XML.
> >> It is Spring approach what can be confusing to non-Java users, and
> >> it is not going to change regardless of format.
> >>
> >> Best Regards,
> >> Igor
> >>
> >> On Tue, May 15, 2018 at 12:15 PM, Dmitriy Govorukhin <
> >> dmitriy.govorukhin@gmail.com> wrote:
> >>
> >> > Folks,
> >> >
> >> > I guess when work on a thin client will be completed, we get more
> >> newcomers
> >> > who use go/python/php/js.
> >> > And we can do ignite more friendly for them, support familiar formats
> for
> >> > configuration.
> >> >
> >> > On Tue, May 15, 2018 at 12:13 PM, Dmitry Pavlov <
> dpavlov.spb@gmail.com>
> >> > wrote:
> >> >
> >> > > Hi Igniters,
> >> > >
> >> > > In general I aggree with adding new format, e.g. JSON is more
> popular
> >> > than
> >> > > XML for new applications.
> >> > >
> >> > > In the same time I've never heard that user asked this in the user
> >> list.
> >> > Or
> >> > > did I missed such topics?
> >> > >
> >> > > Sincerely,
> >> > > Dmitriy Pavlov
> >> > >
> >> > > вт, 15 мая 2018 г. в 9:31, Pavel Tupitsyn <pt...@apache.org>:
> >> > >
> >> > > > Dmitriy,
> >> > > >
> >> > > > We don't need to support different config formats on server in
> order
> >> to
> >> > > add
> >> > > > that to thin clients.
> >> > > >
> >> > > > Thin client protocol provides a way to create a cache with custom
> >> > config
> >> > > > [1].
> >> > > > It is up to thin client library authors to use any config format
> they
> >> > > like
> >> > > > and then convert it into protocol-defined format.
> >> > > >
> >> > > > C# thin client uses custom format, for example, not Spring.
> >> > > >
> >> > > > [1]
> >> > > >
> >> > > > https://apacheignite.readme.io/docs/binary-client-
> >> > > protocol-cache-configuration-operations#section-op_cache_
> >> > > create_with_configuration
> >> > > >
> >> > > > On Mon, May 14, 2018 at 7:54 PM, Ivan Rakov <
> ivan.glukos@gmail.com>
> >> > > wrote:
> >> > > >
> >> > > > > Dmitry,
> >> > > > >
> >> > > > > We rely on Spring Framework when we start Ignite node from XML
> >> > > > > configuration. Spring doesn't easily support another formats of
> >> > > > > configuration files. I think, the main reason for this is
> built-in
> >> > > > ability
> >> > > > > to validate configuration via XML Schema. We can surely hack
> this
> >> > > around
> >> > > > (I
> >> > > > > bet there are existing libraries for configuring Spring with
> JSON),
> >> > > but I
> >> > > > > don't think that anyone suffered from inability to statically
> >> > configure
> >> > > > > Ignite with json/yaml.
> >> > > > >
> >> > > > > Regarding thin clients: makes sense. I suppose necessary
> mappings
> >> > will
> >> > > be
> >> > > > > implemented as a part of thin client.
> >> > > > >
> >> > > > > Best Regards,
> >> > > > > Ivan Rakov
> >> > > > >
> >> > > > >
> >> > > > > On 14.05.2018 18:58, Dmitriy Govorukhin wrote:
> >> > > > >
> >> > > > >> Hi, Igniters!
> >> > > > >>
> >> > > > >> As far as I know, many people work on a thin client for
> different
> >> > > > language
> >> > > > >> (go,js,php...).
> >> > > > >> Are there any reasons why ignite does not support yaml or json
> >> > format
> >> > > > for
> >> > > > >> configuration? or some other popular format?
> >> > > > >> In future, it can help to integrate with thin clients, for
> >> example,
> >> > js
> >> > > > >> client may want to dynamic cache start, he passes cache
> >> > configuration
> >> > > > (in
> >> > > > >> native format, for js it will json) through TCP, Ignite node
> >> unwrap
> >> > > and
> >> > > > >> remap to java representation and dynamic start cache.
> >> > > > >>
> >> > > > >>
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>

Re: supporting different configuration format json,yaml...

Posted by Andrey Gura <ag...@apache.org>.

Actually sometimes users ask about JSON configuration (e.g. was PR in
vertx-ignite project). But it's non trivial task because it will
require development of some DSL (or set of DSL's) and will make adding
new configuration elements some kind of pain while we should be
focused on basic functionality: data grid, persistence, etc.

I just believe that configuration format is not so important aspect
and this task is out of product scope.



On Tue, May 15, 2018 at 12:56 PM, Dmitriy Setrakyan
<ds...@apache.org> wrote:
> I still do not understand *why* do we need to add additional formats for
> the configuration. Can you please show me some users on the user@ list or
> stack overflow who asked for it? I just want to make sure that if we are
> creating work for ourselves, then someone actually needs it.
>
> D.
>
> On Tue, May 15, 2018 at 12:41 PM, Igor Sapego <is...@apache.org> wrote:
>
>> I don't think we need to add new formats on server side as there may
>> be a lot of different formats for different clients. On the other hand,
>> supporting additional formats may be non trivial and error-prone, while
>> adding little to a user experience.
>>
>> For clients, I see no problem in adding for example JSON -> XML
>> converter on client side, if JS folks need it.
>>
>> For servers, adding another configuration format just to make it more
>> familiar to users with no Java background seems unreasonable to me
>> as well, as there still going to be Java class names in configuration
>> and Spring approach in general.
>>
>> What will change is a XML formatting is going to change to JSON
>> formatting, which has no much sense to me, as everyone know XML.
>> It is Spring approach what can be confusing to non-Java users, and
>> it is not going to change regardless of format.
>>
>> Best Regards,
>> Igor
>>
>> On Tue, May 15, 2018 at 12:15 PM, Dmitriy Govorukhin <
>> dmitriy.govorukhin@gmail.com> wrote:
>>
>> > Folks,
>> >
>> > I guess when work on a thin client will be completed, we get more
>> newcomers
>> > who use go/python/php/js.
>> > And we can do ignite more friendly for them, support familiar formats for
>> > configuration.
>> >
>> > On Tue, May 15, 2018 at 12:13 PM, Dmitry Pavlov <dp...@gmail.com>
>> > wrote:
>> >
>> > > Hi Igniters,
>> > >
>> > > In general I aggree with adding new format, e.g. JSON is more popular
>> > than
>> > > XML for new applications.
>> > >
>> > > In the same time I've never heard that user asked this in the user
>> list.
>> > Or
>> > > did I missed such topics?
>> > >
>> > > Sincerely,
>> > > Dmitriy Pavlov
>> > >
>> > > вт, 15 мая 2018 г. в 9:31, Pavel Tupitsyn <pt...@apache.org>:
>> > >
>> > > > Dmitriy,
>> > > >
>> > > > We don't need to support different config formats on server in order
>> to
>> > > add
>> > > > that to thin clients.
>> > > >
>> > > > Thin client protocol provides a way to create a cache with custom
>> > config
>> > > > [1].
>> > > > It is up to thin client library authors to use any config format they
>> > > like
>> > > > and then convert it into protocol-defined format.
>> > > >
>> > > > C# thin client uses custom format, for example, not Spring.
>> > > >
>> > > > [1]
>> > > >
>> > > > https://apacheignite.readme.io/docs/binary-client-
>> > > protocol-cache-configuration-operations#section-op_cache_
>> > > create_with_configuration
>> > > >
>> > > > On Mon, May 14, 2018 at 7:54 PM, Ivan Rakov <iv...@gmail.com>
>> > > wrote:
>> > > >
>> > > > > Dmitry,
>> > > > >
>> > > > > We rely on Spring Framework when we start Ignite node from XML
>> > > > > configuration. Spring doesn't easily support another formats of
>> > > > > configuration files. I think, the main reason for this is built-in
>> > > > ability
>> > > > > to validate configuration via XML Schema. We can surely hack this
>> > > around
>> > > > (I
>> > > > > bet there are existing libraries for configuring Spring with JSON),
>> > > but I
>> > > > > don't think that anyone suffered from inability to statically
>> > configure
>> > > > > Ignite with json/yaml.
>> > > > >
>> > > > > Regarding thin clients: makes sense. I suppose necessary mappings
>> > will
>> > > be
>> > > > > implemented as a part of thin client.
>> > > > >
>> > > > > Best Regards,
>> > > > > Ivan Rakov
>> > > > >
>> > > > >
>> > > > > On 14.05.2018 18:58, Dmitriy Govorukhin wrote:
>> > > > >
>> > > > >> Hi, Igniters!
>> > > > >>
>> > > > >> As far as I know, many people work on a thin client for different
>> > > > language
>> > > > >> (go,js,php...).
>> > > > >> Are there any reasons why ignite does not support yaml or json
>> > format
>> > > > for
>> > > > >> configuration? or some other popular format?
>> > > > >> In future, it can help to integrate with thin clients, for
>> example,
>> > js
>> > > > >> client may want to dynamic cache start, he passes cache
>> > configuration
>> > > > (in
>> > > > >> native format, for js it will json) through TCP, Ignite node
>> unwrap
>> > > and
>> > > > >> remap to java representation and dynamic start cache.
>> > > > >>
>> > > > >>
>> > > > >
>> > > >
>> > >
>> >
>>

Re: supporting different configuration format json,yaml...

Posted by Dmitriy Setrakyan <ds...@apache.org>.

I still do not understand *why* do we need to add additional formats for
the configuration. Can you please show me some users on the user@ list or
stack overflow who asked for it? I just want to make sure that if we are
creating work for ourselves, then someone actually needs it.

D.

On Tue, May 15, 2018 at 12:41 PM, Igor Sapego <is...@apache.org> wrote:

> I don't think we need to add new formats on server side as there may
> be a lot of different formats for different clients. On the other hand,
> supporting additional formats may be non trivial and error-prone, while
> adding little to a user experience.
>
> For clients, I see no problem in adding for example JSON -> XML
> converter on client side, if JS folks need it.
>
> For servers, adding another configuration format just to make it more
> familiar to users with no Java background seems unreasonable to me
> as well, as there still going to be Java class names in configuration
> and Spring approach in general.
>
> What will change is a XML formatting is going to change to JSON
> formatting, which has no much sense to me, as everyone know XML.
> It is Spring approach what can be confusing to non-Java users, and
> it is not going to change regardless of format.
>
> Best Regards,
> Igor
>
> On Tue, May 15, 2018 at 12:15 PM, Dmitriy Govorukhin <
> dmitriy.govorukhin@gmail.com> wrote:
>
> > Folks,
> >
> > I guess when work on a thin client will be completed, we get more
> newcomers
> > who use go/python/php/js.
> > And we can do ignite more friendly for them, support familiar formats for
> > configuration.
> >
> > On Tue, May 15, 2018 at 12:13 PM, Dmitry Pavlov <dp...@gmail.com>
> > wrote:
> >
> > > Hi Igniters,
> > >
> > > In general I aggree with adding new format, e.g. JSON is more popular
> > than
> > > XML for new applications.
> > >
> > > In the same time I've never heard that user asked this in the user
> list.
> > Or
> > > did I missed such topics?
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > вт, 15 мая 2018 г. в 9:31, Pavel Tupitsyn <pt...@apache.org>:
> > >
> > > > Dmitriy,
> > > >
> > > > We don't need to support different config formats on server in order
> to
> > > add
> > > > that to thin clients.
> > > >
> > > > Thin client protocol provides a way to create a cache with custom
> > config
> > > > [1].
> > > > It is up to thin client library authors to use any config format they
> > > like
> > > > and then convert it into protocol-defined format.
> > > >
> > > > C# thin client uses custom format, for example, not Spring.
> > > >
> > > > [1]
> > > >
> > > > https://apacheignite.readme.io/docs/binary-client-
> > > protocol-cache-configuration-operations#section-op_cache_
> > > create_with_configuration
> > > >
> > > > On Mon, May 14, 2018 at 7:54 PM, Ivan Rakov <iv...@gmail.com>
> > > wrote:
> > > >
> > > > > Dmitry,
> > > > >
> > > > > We rely on Spring Framework when we start Ignite node from XML
> > > > > configuration. Spring doesn't easily support another formats of
> > > > > configuration files. I think, the main reason for this is built-in
> > > > ability
> > > > > to validate configuration via XML Schema. We can surely hack this
> > > around
> > > > (I
> > > > > bet there are existing libraries for configuring Spring with JSON),
> > > but I
> > > > > don't think that anyone suffered from inability to statically
> > configure
> > > > > Ignite with json/yaml.
> > > > >
> > > > > Regarding thin clients: makes sense. I suppose necessary mappings
> > will
> > > be
> > > > > implemented as a part of thin client.
> > > > >
> > > > > Best Regards,
> > > > > Ivan Rakov
> > > > >
> > > > >
> > > > > On 14.05.2018 18:58, Dmitriy Govorukhin wrote:
> > > > >
> > > > >> Hi, Igniters!
> > > > >>
> > > > >> As far as I know, many people work on a thin client for different
> > > > language
> > > > >> (go,js,php...).
> > > > >> Are there any reasons why ignite does not support yaml or json
> > format
> > > > for
> > > > >> configuration? or some other popular format?
> > > > >> In future, it can help to integrate with thin clients, for
> example,
> > js
> > > > >> client may want to dynamic cache start, he passes cache
> > configuration
> > > > (in
> > > > >> native format, for js it will json) through TCP, Ignite node
> unwrap
> > > and
> > > > >> remap to java representation and dynamic start cache.
> > > > >>
> > > > >>
> > > > >
> > > >
> > >
> >
>

Re: supporting different configuration format json,yaml...

Posted by Igor Sapego <is...@apache.org>.

I don't think we need to add new formats on server side as there may
be a lot of different formats for different clients. On the other hand,
supporting additional formats may be non trivial and error-prone, while
adding little to a user experience.

For clients, I see no problem in adding for example JSON -> XML
converter on client side, if JS folks need it.

For servers, adding another configuration format just to make it more
familiar to users with no Java background seems unreasonable to me
as well, as there still going to be Java class names in configuration
and Spring approach in general.

What will change is a XML formatting is going to change to JSON
formatting, which has no much sense to me, as everyone know XML.
It is Spring approach what can be confusing to non-Java users, and
it is not going to change regardless of format.

Best Regards,
Igor

On Tue, May 15, 2018 at 12:15 PM, Dmitriy Govorukhin <
dmitriy.govorukhin@gmail.com> wrote:

> Folks,
>
> I guess when work on a thin client will be completed, we get more newcomers
> who use go/python/php/js.
> And we can do ignite more friendly for them, support familiar formats for
> configuration.
>
> On Tue, May 15, 2018 at 12:13 PM, Dmitry Pavlov <dp...@gmail.com>
> wrote:
>
> > Hi Igniters,
> >
> > In general I aggree with adding new format, e.g. JSON is more popular
> than
> > XML for new applications.
> >
> > In the same time I've never heard that user asked this in the user list.
> Or
> > did I missed such topics?
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > вт, 15 мая 2018 г. в 9:31, Pavel Tupitsyn <pt...@apache.org>:
> >
> > > Dmitriy,
> > >
> > > We don't need to support different config formats on server in order to
> > add
> > > that to thin clients.
> > >
> > > Thin client protocol provides a way to create a cache with custom
> config
> > > [1].
> > > It is up to thin client library authors to use any config format they
> > like
> > > and then convert it into protocol-defined format.
> > >
> > > C# thin client uses custom format, for example, not Spring.
> > >
> > > [1]
> > >
> > > https://apacheignite.readme.io/docs/binary-client-
> > protocol-cache-configuration-operations#section-op_cache_
> > create_with_configuration
> > >
> > > On Mon, May 14, 2018 at 7:54 PM, Ivan Rakov <iv...@gmail.com>
> > wrote:
> > >
> > > > Dmitry,
> > > >
> > > > We rely on Spring Framework when we start Ignite node from XML
> > > > configuration. Spring doesn't easily support another formats of
> > > > configuration files. I think, the main reason for this is built-in
> > > ability
> > > > to validate configuration via XML Schema. We can surely hack this
> > around
> > > (I
> > > > bet there are existing libraries for configuring Spring with JSON),
> > but I
> > > > don't think that anyone suffered from inability to statically
> configure
> > > > Ignite with json/yaml.
> > > >
> > > > Regarding thin clients: makes sense. I suppose necessary mappings
> will
> > be
> > > > implemented as a part of thin client.
> > > >
> > > > Best Regards,
> > > > Ivan Rakov
> > > >
> > > >
> > > > On 14.05.2018 18:58, Dmitriy Govorukhin wrote:
> > > >
> > > >> Hi, Igniters!
> > > >>
> > > >> As far as I know, many people work on a thin client for different
> > > language
> > > >> (go,js,php...).
> > > >> Are there any reasons why ignite does not support yaml or json
> format
> > > for
> > > >> configuration? or some other popular format?
> > > >> In future, it can help to integrate with thin clients, for example,
> js
> > > >> client may want to dynamic cache start, he passes cache
> configuration
> > > (in
> > > >> native format, for js it will json) through TCP, Ignite node unwrap
> > and
> > > >> remap to java representation and dynamic start cache.
> > > >>
> > > >>
> > > >
> > >
> >
>

Re: supporting different configuration format json,yaml...

Posted by Dmitriy Govorukhin <dm...@gmail.com>.

Folks,

I guess when work on a thin client will be completed, we get more newcomers
who use go/python/php/js.
And we can do ignite more friendly for them, support familiar formats for
configuration.

On Tue, May 15, 2018 at 12:13 PM, Dmitry Pavlov <dp...@gmail.com>
wrote:

> Hi Igniters,
>
> In general I aggree with adding new format, e.g. JSON is more popular than
> XML for new applications.
>
> In the same time I've never heard that user asked this in the user list. Or
> did I missed such topics?
>
> Sincerely,
> Dmitriy Pavlov
>
> вт, 15 мая 2018 г. в 9:31, Pavel Tupitsyn <pt...@apache.org>:
>
> > Dmitriy,
> >
> > We don't need to support different config formats on server in order to
> add
> > that to thin clients.
> >
> > Thin client protocol provides a way to create a cache with custom config
> > [1].
> > It is up to thin client library authors to use any config format they
> like
> > and then convert it into protocol-defined format.
> >
> > C# thin client uses custom format, for example, not Spring.
> >
> > [1]
> >
> > https://apacheignite.readme.io/docs/binary-client-
> protocol-cache-configuration-operations#section-op_cache_
> create_with_configuration
> >
> > On Mon, May 14, 2018 at 7:54 PM, Ivan Rakov <iv...@gmail.com>
> wrote:
> >
> > > Dmitry,
> > >
> > > We rely on Spring Framework when we start Ignite node from XML
> > > configuration. Spring doesn't easily support another formats of
> > > configuration files. I think, the main reason for this is built-in
> > ability
> > > to validate configuration via XML Schema. We can surely hack this
> around
> > (I
> > > bet there are existing libraries for configuring Spring with JSON),
> but I
> > > don't think that anyone suffered from inability to statically configure
> > > Ignite with json/yaml.
> > >
> > > Regarding thin clients: makes sense. I suppose necessary mappings will
> be
> > > implemented as a part of thin client.
> > >
> > > Best Regards,
> > > Ivan Rakov
> > >
> > >
> > > On 14.05.2018 18:58, Dmitriy Govorukhin wrote:
> > >
> > >> Hi, Igniters!
> > >>
> > >> As far as I know, many people work on a thin client for different
> > language
> > >> (go,js,php...).
> > >> Are there any reasons why ignite does not support yaml or json format
> > for
> > >> configuration? or some other popular format?
> > >> In future, it can help to integrate with thin clients, for example, js
> > >> client may want to dynamic cache start, he passes cache configuration
> > (in
> > >> native format, for js it will json) through TCP, Ignite node unwrap
> and
> > >> remap to java representation and dynamic start cache.
> > >>
> > >>
> > >
> >
>

Re: supporting different configuration format json,yaml...

Posted by Dmitry Pavlov <dp...@gmail.com>.

Hi Igniters,

In general I aggree with adding new format, e.g. JSON is more popular than
XML for new applications.

In the same time I've never heard that user asked this in the user list. Or
did I missed such topics?

Sincerely,
Dmitriy Pavlov

вт, 15 мая 2018 г. в 9:31, Pavel Tupitsyn <pt...@apache.org>:

> Dmitriy,
>
> We don't need to support different config formats on server in order to add
> that to thin clients.
>
> Thin client protocol provides a way to create a cache with custom config
> [1].
> It is up to thin client library authors to use any config format they like
> and then convert it into protocol-defined format.
>
> C# thin client uses custom format, for example, not Spring.
>
> [1]
>
> https://apacheignite.readme.io/docs/binary-client-protocol-cache-configuration-operations#section-op_cache_create_with_configuration
>
> On Mon, May 14, 2018 at 7:54 PM, Ivan Rakov <iv...@gmail.com> wrote:
>
> > Dmitry,
> >
> > We rely on Spring Framework when we start Ignite node from XML
> > configuration. Spring doesn't easily support another formats of
> > configuration files. I think, the main reason for this is built-in
> ability
> > to validate configuration via XML Schema. We can surely hack this around
> (I
> > bet there are existing libraries for configuring Spring with JSON), but I
> > don't think that anyone suffered from inability to statically configure
> > Ignite with json/yaml.
> >
> > Regarding thin clients: makes sense. I suppose necessary mappings will be
> > implemented as a part of thin client.
> >
> > Best Regards,
> > Ivan Rakov
> >
> >
> > On 14.05.2018 18:58, Dmitriy Govorukhin wrote:
> >
> >> Hi, Igniters!
> >>
> >> As far as I know, many people work on a thin client for different
> language
> >> (go,js,php...).
> >> Are there any reasons why ignite does not support yaml or json format
> for
> >> configuration? or some other popular format?
> >> In future, it can help to integrate with thin clients, for example, js
> >> client may want to dynamic cache start, he passes cache configuration
> (in
> >> native format, for js it will json) through TCP, Ignite node unwrap and
> >> remap to java representation and dynamic start cache.
> >>
> >>
> >
>

Re: supporting different configuration format json,yaml...

Posted by Pavel Tupitsyn <pt...@apache.org>.

Dmitriy,

We don't need to support different config formats on server in order to add
that to thin clients.

Thin client protocol provides a way to create a cache with custom config
[1].
It is up to thin client library authors to use any config format they like
and then convert it into protocol-defined format.

C# thin client uses custom format, for example, not Spring.

[1]
https://apacheignite.readme.io/docs/binary-client-protocol-cache-configuration-operations#section-op_cache_create_with_configuration

On Mon, May 14, 2018 at 7:54 PM, Ivan Rakov <iv...@gmail.com> wrote:

> Dmitry,
>
> We rely on Spring Framework when we start Ignite node from XML
> configuration. Spring doesn't easily support another formats of
> configuration files. I think, the main reason for this is built-in ability
> to validate configuration via XML Schema. We can surely hack this around (I
> bet there are existing libraries for configuring Spring with JSON), but I
> don't think that anyone suffered from inability to statically configure
> Ignite with json/yaml.
>
> Regarding thin clients: makes sense. I suppose necessary mappings will be
> implemented as a part of thin client.
>
> Best Regards,
> Ivan Rakov
>
>
> On 14.05.2018 18:58, Dmitriy Govorukhin wrote:
>
>> Hi, Igniters!
>>
>> As far as I know, many people work on a thin client for different language
>> (go,js,php...).
>> Are there any reasons why ignite does not support yaml or json format for
>> configuration? or some other popular format?
>> In future, it can help to integrate with thin clients, for example, js
>> client may want to dynamic cache start, he passes cache configuration (in
>> native format, for js it will json) through TCP, Ignite node unwrap and
>> remap to java representation and dynamic start cache.
>>
>>
>

Re: supporting different configuration format json,yaml...

Posted by Ivan Rakov <iv...@gmail.com>.

Dmitry,

We rely on Spring Framework when we start Ignite node from XML 
configuration. Spring doesn't easily support another formats of 
configuration files. I think, the main reason for this is built-in 
ability to validate configuration via XML Schema. We can surely hack 
this around (I bet there are existing libraries for configuring Spring 
with JSON), but I don't think that anyone suffered from inability to 
statically configure Ignite with json/yaml.

Regarding thin clients: makes sense. I suppose necessary mappings will 
be implemented as a part of thin client.

Best Regards,
Ivan Rakov

On 14.05.2018 18:58, Dmitriy Govorukhin wrote:
> Hi, Igniters!
>
> As far as I know, many people work on a thin client for different language
> (go,js,php...).
> Are there any reasons why ignite does not support yaml or json format for
> configuration? or some other popular format?
> In future, it can help to integrate with thin clients, for example, js
> client may want to dynamic cache start, he passes cache configuration (in
> native format, for js it will json) through TCP, Ignite node unwrap and
> remap to java representation and dynamic start cache.
>