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
