<div dir="ltr"><div>Trying to run a java parser from the C client sounds like an additional source of deployment/configuration hassles.  Is there a particular reason why it needs to be the client though rather than the Coaster service that handles the configuration?<br>
<br>To me it would make the most sense to either choose a simple constrained format that its feasible to write a custom parser for, or to just use JSON or XML where there are lots of existing parsers.<br><br></div>- Tim<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jul 5, 2014 at 1:03 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 09:34 -0500, Michael Wilde wrote:<br>
> This looks very good, deals with a lot of parsing issues, and is<br>
> licensed under Apache 2 (same as Swift).<br>
><br>
> But is it Java-only?   If so, then down the road, for Swift/T with<br>
> Coaster C client, just parse options using a Java app perhaps?<br>
<br>
</div>It's Java only. I don't know. I guess writing one parser is better than<br>
writing two parsers.<br>
<br>
The only other reasonable choice is XML unless somebody knows something<br>
else.<br>
<div class="HOEnZb"><div class="h5"><br>
Mihael<br>
<br>
<br>
_______________________________________________<br>
Swift-devel mailing list<br>
<a href="mailto:Swift-devel@ci.uchicago.edu">Swift-devel@ci.uchicago.edu</a><br>
<a href="https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel" target="_blank">https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel</a><br>
</div></div></blockquote></div><br></div>