<div dir="ltr"><div><div>> Currently the configuration comes from the client. There is a plan to<br>> have a version of the coaster service where the service is started with<br>> an immutable configuration. This is a relatively different issue. It<br>

> does not need a hierarchical configuration format, and it will most<br>> likely be a flat properties file. So if that addresses the problem<br>> from /T's perspective, then things should be fine.<br><br></div>
I don't think I understand well enough what the pros/cons are here.  With the static configuration, we'd lose the ability for the client to dynamically add new sites or modify other settings - is that the only difference?  I understand that it maybe buys you some flexibility in that you can stand up a coasters service ahead of time, or reuse the same service for Swift runs with different configurations. I don't know if those are likely use cases for Swift/T.  Are there any Coasters settings where there's some other reason the client needs to set it?<br>
<br></div>- Tim<br><div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jul 6, 2014 at 3:55 PM, Mihael Hategan <span dir="ltr"><<a href="mailto:hategan@mcs.anl.gov" target="_blank">hategan@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Sun, 2014-07-06 at 15:01 -0500, Tim Armstrong wrote:<br>
> I think the goal would be to allow the same sites files to be used for<br>
> Swift/K and Swift/T+coasters, right? Currently Swift/T is mainly configured<br>
> through environment variables.<br>
><br>
> It seems like it might make the most sense architecturally in Swift/T for<br>
> the Coaster service to load the config file directly, given that the config<br>
> file will probably just be slurped up and sent to the service anyway.  If<br>
> this was possible it might avoid the issue entirely.<br>
<br>
</div>Currently the configuration comes from the client. There is a plan to<br>
have a version of the coaster service where the service is started with<br>
an immutable configuration. This is a relatively different issue. It<br>
does not need a hierarchical configuration format, and it will most<br>
likely be a flat properties file. So if that addresses the problem<br>
from /T's perspective, then things should be fine.<br>
<div class=""><br>
><br>
> The main issue with using a parser that accepts a superset of the official<br>
> config file syntax is that config files with syntax that "officially" is<br>
> invalid will probably crop up.  In practice this might be a relatively<br>
> small problem but I can see users being confused by it.<br>
<br>
</div>The choice is not that. The choice at the moment is between an in-house<br>
format that isn't well documented, does not specify how special<br>
characters are handled (or expressed), does not escape much (try & in an<br>
environment variable) etc. and a variant of a standard that isn't<br>
completely in-house and that handles the corner cases. Well, that or<br>
back to XML.<br>
<div class=""><br>
><br>
> I do think a custom format would need more documentation than is currently<br>
> in the user guide - there's no mention of how whitespace is handled, for<br>
> example.<br>
<br>
</div>I think everybody agrees that the current documentation isn't quite<br>
right. Fixing that would be part of the change.<br>
<div class=""><br>
><br>
> My two cents is that just parsing it directly from Java will save effort in<br>
> the long run and improve the user experience with better error reporting<br>
> etc.  Having multiple stages of processing also makes it harder to ensure<br>
> that special characters, whitespace, etc is correctly preserved, and makes<br>
> it hard to e.g. provide line numbers in error messages if desired.<br>
<br>
</div>Right. Hence my choice of doing this. An additional difficulty was that<br>
it seemed hard to convince the current translator to accommodate a<br>
more-than-one-nesting-level hierarchical structure.<br>
<br>
There are more benefits, in that there would now be a unified validation<br>
place that checks all configuration values and fails early. This was<br>
previously either missing (for tc.data) or scattered in different places<br>
(providers for sites.xml, the perl code for the sites translator, custom<br>
java code for the other swift properties).<br>
<span class="HOEnZb"><font color="#888888"><br>
Mihael<br>
<br>
</font></span></blockquote></div><br></div>