Re: JSON as a configuration format?

[Dain Sundstrom <da...@iq80.com>]

I agree with Jeremy.

I would hate to loose the simple text based configuration, but I think  
we should make sure that the configuration system plays well with  
popular frameworks like Spring.

-dain

On Aug 29, 2008, at 2:21 PM, Jeremy Haile wrote:

> I agree - I don't think ini is a good tool for defining object  
> graphs - I just also think that most of our users won't want to  
> define object graphs in our file =)
>
> I think most users will view the ini section as basically setting  
> some properties to get things operating correctly.  And I don't  
> think that's a bad thing.  Simplest tool for the job.
>
>
> On Aug 29, 2008, at 3:16 PM, Les Hazlewood wrote:
>
>> Now that I think about about it, because Spring is so XML based, I  
>> would
>> much rather prefer to use json to define Spring configs too  
>> (assuming IDEs
>> would integrate with this nicely as well - click on names, jump to  
>> source
>> code, etc).  I wonder if I should build that and contribute it into  
>> Spring
>> 3.x.  That might be cool.
>>
>> For me this is about the best tool for the job - I believe the
>> .ini/.properties approach is less than ideal for defining object  
>> graphs, and
>> with the advent of json or yaml, so is XML as far as I'm  
>> concerned.  I just
>> think think there are better, cleaner (less verbose) ways...
>>
>> That being said, JSecurity configs are pretty small object graphs,  
>> so its
>> not that big of an issue for our project - I'm just thinking in  
>> general.
>> But if it is something that end-users want, I'd want to support  
>> it.  If no
>> one wants it, that's cool too.
>>
>> On Fri, Aug 29, 2008 at 2:58 PM, Jeremy Haile <jh...@fastmail.fm>  
>> wrote:
>>
>>> I'd think that if the jar footprint was minimal and we made it  
>>> optional,
>>> that's fine.  I just think that INI is probably sufficient and  
>>> simpler to
>>> understand for a large majority of users, so I'd like to see that  
>>> stay the
>>> standard for examples, example apps, etc.
>>>
>>>
>>> On Aug 29, 2008, at 2:51 PM, Les Hazlewood wrote:
>>>
>>> Let's say the parsing-to-object-graph logic was already written -  
>>> e.g. in
>>> another Apache licensed open source framework, and we just used  
>>> it.  What
>>> would you think then?
>>>
>>> On Fri, Aug 29, 2008 at 2:48 PM, Jeremy Haile <jh...@fastmail.fm>  
>>> wrote:
>>>
>>>> My fear is that the JSON syntax is bordering on writing our own  
>>>> "Spring
>>>> framework config" - I'd rather standardize on being able to embed  
>>>> spring
>>>> than invent our own syntax that no one is familiar with.  I'm not  
>>>> against
>>>> options, but personally I think most users will be fine either  
>>>> using the
>>>> simple INI (properties-looking) format or just using Spring for  
>>>> more complex
>>>> situations.
>>>>
>>>> J
>>>>
>>>>
>>>>
>>>> On Aug 29, 2008, at 2:40 PM, Les Hazlewood wrote:
>>>>
>>>> Hi JSecurity Community,
>>>>>
>>>>> I'd like to get your thoughts on something.
>>>>>
>>>>> Currently, JSecurity's only text-based configuration option (in  
>>>>> web.xml
>>>>> or
>>>>> jsecurity.ini) is the INI file format.
>>>>>
>>>>> This format works well enough and seems clean, but it doesn't
>>>>> particularly
>>>>> handle object graph definitions all that well.  But JSecurity
>>>>> configuration
>>>>> is essentially just that - an object graph of the JSecurity
>>>>> SecurityManager
>>>>> and all of its dependencies (realms, etc).
>>>>>
>>>>> JSON might be a better format for object graph definitions, and  
>>>>> might be
>>>>> more succinct than even INI.  Would it be worth having this as the
>>>>> preferred
>>>>> configuration syntax instead?
>>>>>
>>>>> Consider the following definitions:
>>>>>
>>>>> INI:
>>>>>
>>>>> bar = some.domain.package.Bar
>>>>> bar.name = ABar
>>>>> bar.amount = 50.00
>>>>>
>>>>> foo = some.domain.package.Foo
>>>>> foo.something = Some value
>>>>> foo.bar = $bar
>>>>> foo.anotherThing = 52
>>>>>
>>>>> JSON:
>>>>>
>>>>> foo: some.domain.package.Foo {
>>>>> something: Some value,
>>>>> bar: some.domain.package.Bar {
>>>>>     name: ABar,
>>>>>     amount: 50.00
>>>>> },
>>>>> anotherThing: 52
>>>>> }
>>>>>
>>>>> What do you think?  Which one would you prefer?
>>>>>
>>>>> --
>>>>> Les
>>>>>
>>>>
>>>>
>>>
>>>
>