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

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.govoruk...@gmail.com> wrote: > Folks, > > Why do you interpret the question as a necessity for action? > In my first message, "Are there any

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

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 wrote: >

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

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 wrote: > Andrey G, +1 > > > Andrey

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

Andrey G, +1 Andrey K, > json-schema It's a draft. XML schema is a mature standard. > eye fatigue Here is Ignite.NET config: Equivalent JSON excerpt: "cacheConfiguration": { "cacheMode": "Replicated", "name": "myCache" } Enough said I guess :) On Wed, May 16, 2018 at 12:48 AM, Andrey

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

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 : > Pavel, > > One can

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

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] : "

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

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 wrote:

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

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

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

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 : > Guys, if you think the YAML or JSON would be better, how about > you provide us a

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

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 wrote: >

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

Hello! Maybe we should take .Net configuration as a standard, extend it to JSON and YAML? 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

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

+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 "", "" - terms which say nothing

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

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

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

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

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

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 wrote: > Hi Igniters, > >

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

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

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

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

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

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