[Swift-devel] changes

[Mihael Hategan]

On Sat, 2014-07-05 at 20:28 -0500, Tim Armstrong wrote:
> 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?

It's not just coasters. This applies to all of Swift/K, and includes all
the options, site and app definitions. Coasters are a small part, and
stand-alone coasters where the service would have a single static
configuration is an even smaller part.

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

Yeah, and there's the problem.
We have a new config mechanism that Mike and David developed. It's very
nice to the eyes. It's supposed to be the next configuration format for
swift. It's almost JSON, except for a few syntactic sugary things.
JSON's habit of quoting every key is noisy, probably more so than XML.

I'm taking that format and using a pre-existing library to do the
parsing and skipping intermediate XML files.

We can argue a few points:
- do we really want this new format given that it's non-standard and
there is some unclear as of yet need to have something maybe similar in
Swift/T?
- if we do, do we want it to be implemented as a custom perl translator
to XML and then a Java XML parser, or a Java direct parser?
- do Swift/T and K really need to have the same configuration format
when they differ in so many other respects?

Mihael