Shibboleth Developers

["Scott Cantor" <>]

> Just a minor note that things like forgetting to type 'newaliases' or
> 'commit;' or 'make' to rebuild some embedded database, etc. are legend
> among sysadmin errors, and systems that don't require such handholding
> -- e.g. the shib SP -- are much appreciated by myself and others ;)

One of my assumptions is that it would be possible to embed the make command
in the init scripts to automate the conversion, but that doesn't work for
Windows or address the restart problem.

One thought is to be able to log a warning periodically if the "new" config
(assuming I can guess or default the filename) is newer than the XML file.

> So if someone's needs "outgrow" what's possible with the simple format
> they'd have to "graduate" to using the resulting XML file? That's fine
> as long as you're confident the simple format can handle many cases
> (i.e., are most cases simple? Difficult to find out).

It has to work that way no matter how it's implemented, and the whole basis
of the addition is that there are enough simple cases worth addressing. If
not, it's wasted effort (in which case I guess I can stop listening to
people who say it's too complex now?)

But I need feedback from people about what they're changing, yes. I think
even my early thoughts go pretty far into the kinds of things people do.

> And even then
> the learning curve actually becomes steeper because then people
> haven't used the XML format at all (not even for small/trivial
> changes) until they need to do more complex configurations.

My impression is that people are learning little to nothing now. At least
that's my experience here. They can figure out how to make changes they're
told to make without screwing the XML up after some trial and error but that
there's very little "understanding" of the XML. There are obviously plenty
of exceptions to that, but that's my overall sense.

> So to avoid features creeping into the simple format (which would
> ultimately end up providing all the features of the XML format but in
> a non-XML syntax) there'd have to be some guidelines of when (not) to
> add more config elements to the simple format. Because I'd expect
> people to always "want more" and I don't think the idea of the simple
> format is just to get rid of XML?

No, it's not the idea to do that, and I agree it would be a judgement call.
But if there are settings that are simple to support, I can't see a good
reason not to allow them. The big difference is that they would be invisible
to anyone that didn't care about them because the new file won't include
"defaults" that people have to ignore or avoid changing.

And sadly, a large reason for doing this is to support things in a non-XML
syntax.

> The attribute filter/map, logging config (which isn't XML even now)
> etc. would all stay the same? Just asking.

Yes, I mentioned that in the page. I could do a non-XML map (the filter
would be pretty tough), but it doesn't really seem worth doing. The map XML
is much simpler and more uniform than the main file.

Thanks, 
-- Scott