<div dir="ltr"><div>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.<br><br></div>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.<br>
<div><br>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.<br>
<br></div><div>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.<br></div><div><br></div><div>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.<br>
</div><div><br></div><div>- Tim<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jul 5, 2014 at 9:16 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 Sat, 2014-07-05 at 20:28 -0500, Tim Armstrong wrote:<br>
> Trying to run a java parser from the C client sounds like an additional<br>
> source of deployment/configuration hassles.  Is there a particular reason<br>
> why it needs to be the client though rather than the Coaster service that<br>
> handles the configuration?<br>
<br>
</div>It's not just coasters. This applies to all of Swift/K, and includes all<br>
the options, site and app definitions. Coasters are a small part, and<br>
stand-alone coasters where the service would have a single static<br>
configuration is an even smaller part.<br>
<div class=""><br>
><br>
> To me it would make the most sense to either choose a simple constrained<br>
> format that its feasible to write a custom parser for, or to just use JSON<br>
> or XML where there are lots of existing parsers.<br>
<br>
</div>Yeah, and there's the problem.<br>
We have a new config mechanism that Mike and David developed. It's very<br>
nice to the eyes. It's supposed to be the next configuration format for<br>
swift. It's almost JSON, except for a few syntactic sugary things.<br>
JSON's habit of quoting every key is noisy, probably more so than XML.<br>
<br>
I'm taking that format and using a pre-existing library to do the<br>
parsing and skipping intermediate XML files.<br>
<br>
We can argue a few points:<br>
- do we really want this new format given that it's non-standard and<br>
there is some unclear as of yet need to have something maybe similar in<br>
Swift/T?<br>
- if we do, do we want it to be implemented as a custom perl translator<br>
to XML and then a Java XML parser, or a Java direct parser?<br>
- do Swift/T and K really need to have the same configuration format<br>
when they differ in so many other respects?<br>
<span class="HOEnZb"><font color="#888888"><br>
Mihael<br>
<br>
</font></span></blockquote></div><br></div>