ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ilya Kasnacheev <ilya.kasnach...@gmail.com>
Subject Re: supporting different configuration format json,yaml...
Date Tue, 15 May 2018 13:20:18 GMT
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
> > <dsetrakyan@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.
> > >> > > > >>
> > >> > > > >>
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
>

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