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 via email to