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 <ptupit...@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 <isap...@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 <jokse...@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 <isap...@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.kasnach...@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 <jokse...@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 > > > > > > > <dsetrak...@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 < > > > isap...@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.govoruk...@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....@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 < > > > > ptupit...@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.glu...@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.
