[Swift-devel] changes

[Tim Armstrong]

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.

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.

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.

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.

- Tim


On Sat, Jul 5, 2014 at 9:16 PM, Mihael Hategan <hategan at mcs.anl.gov> wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20140706/4285ed0b/attachment.html>