JSON as a configuration format?

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

JSON as a configuration format?

Les Hazlewood
Administrator
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JSON as a configuration format?

Jeremy Haile
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JSON as a configuration format?

Les Hazlewood
Administrator
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 <[hidden email]> 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
>>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JSON as a configuration format?

Jeremy Haile
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 <[hidden email]>  
> 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
>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JSON as a configuration format?

Les Hazlewood
Administrator
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 <[hidden email]> 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 <[hidden email]> 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
>>>
>>
>>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JSON as a configuration format?

Jeremy Haile
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 <[hidden email]>  
> 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 <[hidden email]>  
>> 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
>>>>
>>>
>>>
>>
>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JSON as a configuration format?

Alan D. Cabrera
In reply to this post by Jeremy Haile
I like the JSON syntax.

Why does the project need to standardize on a few configuration  
mechanisms?


Regards,
Alan


On Aug 29, 2008, at 11:48 AM, Jeremy Haile 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
>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JSON as a configuration format?

Jeremy Haile
So that it's simple for users to understand and people don't get  
confused on what they're supposed to use to get started.


On Aug 29, 2008, at 3:48 PM, Alan D. Cabrera wrote:

> I like the JSON syntax.
>
> Why does the project need to standardize on a few configuration  
> mechanisms?
>
>
> Regards,
> Alan
>
>
> On Aug 29, 2008, at 11:48 AM, Jeremy Haile 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
>>
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JSON as a configuration format?

Alan D. Cabrera
That's an argument for having a simple config system available for  
novice users and for good documentation, not for constraining the set  
of ways people can configure.


Regards,
Alan

On Aug 29, 2008, at 12:50 PM, Jeremy Haile wrote:

> So that it's simple for users to understand and people don't get  
> confused on what they're supposed to use to get started.
>
>
> On Aug 29, 2008, at 3:48 PM, Alan D. Cabrera wrote:
>
>> I like the JSON syntax.
>>
>> Why does the project need to standardize on a few configuration  
>> mechanisms?
>>
>>
>> Regards,
>> Alan
>>
>>
>> On Aug 29, 2008, at 11:48 AM, Jeremy Haile 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
>>>
>>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JSON as a configuration format?

Les Hazlewood
Administrator
In reply to this post by Alan D. Cabrera
I don't think it needs to 'standardized' per se - of course, having a
Configuration interface allows an implementor to use use any format
imaginable.

But I think Jeremy wants for the dev team a 'preferred' mechanism to use in
examples so we don't have to write all our config examples twice.  Whatever
that preferred choice is however, it would naturally steer new members of
our community in whatever direction we prefer - i.e. path of least
resistence.

I don't know that I have an opinion one way or the other.  I think I'm
leaning toward json at the moment as the 'preferred' format, only because it
makes more sense to me in what it represents.  But the .ini format is
probably easier to read if your configuration is trivial, as most configs
probably will be.

The json format is probably easier to read in the cases where the config is
more complicated.  It is certainly less verbose in either case.  But I don't
mind if .ini stays the preferred format either.

I feel 'pick what works best for you'.  Its kinda like XML vs Annotations -
sometimes some people just have preferences....

On Fri, Aug 29, 2008 at 3:48 PM, Alan D. Cabrera <[hidden email]>wrote:

> I like the JSON syntax.
>
> Why does the project need to standardize on a few configuration mechanisms?
>
>
> Regards,
> Alan
>
>
>
> On Aug 29, 2008, at 11:48 AM, Jeremy Haile 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
>>>
>>
>>
>>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JSON as a configuration format?

Les Hazlewood
Administrator
In reply to this post by Alan D. Cabrera
Yep, that's true.  But because we have a Configuration and WebConfiguration
interface, no one is really constrained per se - anyone can implement any
format/parser they wish - even XML if someone really wanted that ;)

Although at the moment, we haven't written anything other than .ini parsing,
so the only constraint is that other options aren't readily available in our
distribution...

On Fri, Aug 29, 2008 at 3:57 PM, Alan D. Cabrera <[hidden email]>wrote:

> That's an argument for having a simple config system available for novice
> users and for good documentation, not for constraining the set of ways
> people can configure.
>
>
> Regards,
> Alan
>
>
> On Aug 29, 2008, at 12:50 PM, Jeremy Haile wrote:
>
>  So that it's simple for users to understand and people don't get confused
>> on what they're supposed to use to get started.
>>
>>
>> On Aug 29, 2008, at 3:48 PM, Alan D. Cabrera wrote:
>>
>>  I like the JSON syntax.
>>>
>>> Why does the project need to standardize on a few configuration
>>> mechanisms?
>>>
>>>
>>> Regards,
>>> Alan
>>>
>>>
>>> On Aug 29, 2008, at 11:48 AM, Jeremy Haile 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
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JSON as a configuration format?

Les Hazlewood-2
Maybe this is an area where, if it is wanted by end users, they could join
our community and become committers and contribute to the project?  Anyone
writing a configuration implementation would need to know how the JSecurity
components work together (somewhat), and this kind of exercise would be a
good way to become a team member...

On Fri, Aug 29, 2008 at 4:01 PM, Les Hazlewood <[hidden email]> wrote:

> Yep, that's true.  But because we have a Configuration and WebConfiguration
> interface, no one is really constrained per se - anyone can implement any
> format/parser they wish - even XML if someone really wanted that ;)
>
> Although at the moment, we haven't written anything other than .ini
> parsing, so the only constraint is that other options aren't readily
> available in our distribution...
>
>
> On Fri, Aug 29, 2008 at 3:57 PM, Alan D. Cabrera <[hidden email]>wrote:
>
>> That's an argument for having a simple config system available for novice
>> users and for good documentation, not for constraining the set of ways
>> people can configure.
>>
>>
>> Regards,
>> Alan
>>
>>
>> On Aug 29, 2008, at 12:50 PM, Jeremy Haile wrote:
>>
>>  So that it's simple for users to understand and people don't get confused
>>> on what they're supposed to use to get started.
>>>
>>>
>>> On Aug 29, 2008, at 3:48 PM, Alan D. Cabrera wrote:
>>>
>>>  I like the JSON syntax.
>>>>
>>>> Why does the project need to standardize on a few configuration
>>>> mechanisms?
>>>>
>>>>
>>>> Regards,
>>>> Alan
>>>>
>>>>
>>>> On Aug 29, 2008, at 11:48 AM, Jeremy Haile 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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JSON as a configuration format?

Emmanuel Lécharny
In reply to this post by Les Hazlewood
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?
>  
Interesting question ...

I feel like we may have many different opinions, so reaching a consensus
will be difficult. But I don't think that's necessary.

Obviously, JSON syntax is way easier to read, and less error prone. But
you need an external parser (ie, more dependencies, something you don't
like and want, les ;).

Compared to some Spring based stuff (yerkkk...), this is also lighter,
and you need less jars, plus you won't have the problems spring has (ie,
object instanciation, heavy RTFM in order to understand all the possible
options, etc). If we can avoid Spring, that would be better...

Now, Alan raised an interesting point, and your response was pretty
smart too.  Maybe it's better to think about defining more than one
configuration parser, and let the user chose, instead of changing the
configuration, and force the user to get stuck with something he is not
familiar with (JSon is not well knwn). Obviously, this will lead to more
documentation, but it's more versatile. A bit like Log4j configuration
choice (between a .ini or a super heavy xml file ;)

Last, not least, the best configuration will always be the one which
help the user to know where he has made a mistake...

If it comes to make a choice, then I would pick JSON.
> --
> Les
>
>  


--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JSON as a configuration format?

Jeremy Haile
I'm not against multiple formats as long as we keep the basic  
integration as simple as possible.  *Most user don't need anything  
more than just setting a few properties, so even ini bean  
configuration is overkill in most cases.*

I'd much rather be spending our time writing a cool expression  
language for security annotations, supporting more out-of-the-box  
realms and configurations, writing better documentation, figuring out  
how to integrate better with other security systems, working on better  
SSO support, etc. rather than supporting different configuration  
options which is something I don't feel like many if any users are  
asking for.

I'm not trying to be a downer here, but I think simple is better and  
although I fully support multiple options for configuration, it seems  
like there's much better uses of our time.  That being said, this is  
open-source so if you're motivated to work on multiple configuration  
formats before we even have our existing format documented, by all  
means feel free to spend your time there. =)

On Aug 29, 2008, at 4:26 PM, Emmanuel Lecharny wrote:

> 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?
>>
> Interesting question ...
>
> I feel like we may have many different opinions, so reaching a  
> consensus will be difficult. But I don't think that's necessary.
>
> Obviously, JSON syntax is way easier to read, and less error prone.  
> But you need an external parser (ie, more dependencies, something  
> you don't like and want, les ;).
>
> Compared to some Spring based stuff (yerkkk...), this is also  
> lighter, and you need less jars, plus you won't have the problems  
> spring has (ie, object instanciation, heavy RTFM in order to  
> understand all the possible options, etc). If we can avoid Spring,  
> that would be better...
>
> Now, Alan raised an interesting point, and your response was pretty  
> smart too.  Maybe it's better to think about defining more than one  
> configuration parser, and let the user chose, instead of changing  
> the configuration, and force the user to get stuck with something he  
> is not familiar with (JSon is not well knwn). Obviously, this will  
> lead to more documentation, but it's more versatile. A bit like  
> Log4j configuration choice (between a .ini or a super heavy xml  
> file ;)
>
> Last, not least, the best configuration will always be the one which  
> help the user to know where he has made a mistake...
>
> If it comes to make a choice, then I would pick JSON.
>> --
>> Les
>>
>>
>
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JSON as a configuration format?

Emmanuel Lécharny
Jeremy,

I'm not saying that JSecurity should support multiple format. I'm just
saying that when you are thinking about switching from one format to
another, then you have to consider this as an option. Otherwise, I'm on
the same page with what you wrote.

Jeremy Haile wrote:

> I'm not against multiple formats as long as we keep the basic
> integration as simple as possible.  *Most user don't need anything
> more than just setting a few properties, so even ini bean
> configuration is overkill in most cases.*
>
> I'd much rather be spending our time writing a cool expression
> language for security annotations, supporting more out-of-the-box
> realms and configurations, writing better documentation, figuring out
> how to integrate better with other security systems, working on better
> SSO support, etc. rather than supporting different configuration
> options which is something I don't feel like many if any users are
> asking for.
>
> I'm not trying to be a downer here, but I think simple is better and
> although I fully support multiple options for configuration, it seems
> like there's much better uses of our time.  That being said, this is
> open-source so if you're motivated to work on multiple configuration
> formats before we even have our existing format documented, by all
> means feel free to spend your time there. =)
>
> On Aug 29, 2008, at 4:26 PM, Emmanuel Lecharny wrote:
>
>> 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?
>>>
>> Interesting question ...
>>
>> I feel like we may have many different opinions, so reaching a
>> consensus will be difficult. But I don't think that's necessary.
>>
>> Obviously, JSON syntax is way easier to read, and less error prone.
>> But you need an external parser (ie, more dependencies, something you
>> don't like and want, les ;).
>>
>> Compared to some Spring based stuff (yerkkk...), this is also
>> lighter, and you need less jars, plus you won't have the problems
>> spring has (ie, object instanciation, heavy RTFM in order to
>> understand all the possible options, etc). If we can avoid Spring,
>> that would be better...
>>
>> Now, Alan raised an interesting point, and your response was pretty
>> smart too.  Maybe it's better to think about defining more than one
>> configuration parser, and let the user chose, instead of changing the
>> configuration, and force the user to get stuck with something he is
>> not familiar with (JSon is not well knwn). Obviously, this will lead
>> to more documentation, but it's more versatile. A bit like Log4j
>> configuration choice (between a .ini or a super heavy xml file ;)
>>
>> Last, not least, the best configuration will always be the one which
>> help the user to know where he has made a mistake...
>>
>> If it comes to make a choice, then I would pick JSON.
>>> --
>>> Les
>>>
>>>
>>
>>
>> --
>> --
>> cordialement, regards,
>> Emmanuel Lécharny
>> www.iktek.com
>> directory.apache.org
>>
>>
>
>


--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JSON as a configuration format?

Dain Sundstrom
In reply to this post by Jeremy Haile
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 <[hidden email]>  
>> 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 <[hidden email]>  
>>> 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
>>>>>
>>>>
>>>>
>>>
>>>
>

Loading...