[Swift-devel] changes

[Mihael Hategan]

On Sun, 2014-07-06 at 20:35 -0500, Tim Armstrong wrote:
> Right, I get that it's more flexible: I was mainly trying to understand how
> important that flexibility was in practice.
> 
> The main use case I think would be to start a Coaster service at the same
> time as the Swift/T run and tear it down once the run was done: e.g. with a
> launch script that starts both the Coaster service and the Swift run.  It
> sounds like starting a Coaster service pointed at a configuration file
> would achieve exactly the same thing as starting a Coaster service then
> configuring it via the client in this scenario.

Right. If you don't need multiple configurations per service (which is
only a recent practical development), and if you control the starting of
the service, then it's very reasonable to have the settings loaded by
the service.

But I must point out that this is still a somewhat separate issue. Swift
aggregates configurations for multiple such services. It is not (and
should not) be the duty of a service to understand the entire swift
configuration mechanism and extract the relevant pieces out of it,
though given that the service is Java, some custom launcher could do
something like that while re-using whatever swift uses for
configuration.

>   I don't know the config
> mechanism and settings well enough to be confident about that assessment is
> my problem.

I think there are many possibilities here and that makes it a bit murky.

> 
> Anyway, this is fairly academic at the moment :)

Yeah. I don't see this issue as a blocker. Let's talk details when we
have some tangible goal.

Mihael