[Swift-devel] changes

[Mihael Hategan]

On Sun, 2014-07-06 at 15:01 -0500, Tim Armstrong wrote:
> I think the goal would be to allow the same sites files to be used for
> Swift/K and Swift/T+coasters, right? Currently Swift/T is mainly configured
> through environment variables.
> 
> It seems like it might make the most sense architecturally in Swift/T for
> the Coaster service to load the config file directly, given that the config
> file will probably just be slurped up and sent to the service anyway.  If
> this was possible it might avoid the issue entirely.

Currently the configuration comes from the client. There is a plan to
have a version of the coaster service where the service is started with
an immutable configuration. This is a relatively different issue. It
does not need a hierarchical configuration format, and it will most
likely be a flat properties file. So if that addresses the problem
from /T's perspective, then things should be fine.

> 
> The main issue with using a parser that accepts a superset of the official
> config file syntax is that config files with syntax that "officially" is
> invalid will probably crop up.  In practice this might be a relatively
> small problem but I can see users being confused by it.

The choice is not that. The choice at the moment is between an in-house
format that isn't well documented, does not specify how special
characters are handled (or expressed), does not escape much (try & in an
environment variable) etc. and a variant of a standard that isn't
completely in-house and that handles the corner cases. Well, that or
back to XML.

> 
> I do think a custom format would need more documentation than is currently
> in the user guide - there's no mention of how whitespace is handled, for
> example.

I think everybody agrees that the current documentation isn't quite
right. Fixing that would be part of the change.

> 
> My two cents is that just parsing it directly from Java will save effort in
> the long run and improve the user experience with better error reporting
> etc.  Having multiple stages of processing also makes it harder to ensure
> that special characters, whitespace, etc is correctly preserved, and makes
> it hard to e.g. provide line numbers in error messages if desired.

Right. Hence my choice of doing this. An additional difficulty was that
it seemed hard to convince the current translator to accommodate a
more-than-one-nesting-level hierarchical structure.

There are more benefits, in that there would now be a unified validation
place that checks all configuration values and fails early. This was
previously either missing (for tc.data) or scattered in different places
(providers for sites.xml, the perl code for the sites translator, custom
java code for the other swift properties).

Mihael