Shibboleth Developers

[Peter Schober <>]

* Scott Cantor 
<>
 [2010-07-02 02:47]:
> - avoids any complexity in supporting configuration reload, since the
> translation step would overwrite the XML file, and trigger reloads
> normally
[...]
> My expectation for usability is that it would be a command line tool
> scriptable via make on Unix, and a simple Windows applet invoked with a
> Start Menu shortcut on Windows, so it shouldn't be awkward to run the
> translation step. I expect it to just be part of using the SP and making
> changes, for people that want to use the simpler format.

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 ;)
But I guess requests to that regard ("why do may changes not show any
effect") will be rather easy to answer by almost anyone ("did you run
makeFoo?"). Though in some cases (none of which are part of the
current strawman example, AFAICT) one would still need to restart
shibd or maybe eben the webserver, but that's something the
translation tool could warn about, I guess.

> Something I'm not focused on trying to support right now is to allow
> for "customization" of the resulting XML to support adjustments that
> would be in addition to the use cases supported by the new format,
> but the translation approach makes that possible later.

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). 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.
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?

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

cheers,
-peter