[Swift-devel] FQNs use in Swift

[Mihael Hategan]

The reason I'm asking is because I'm trying to fix the various coaster
configuration problems:
- the need to have a "pilot" job to set jobsPerNode
- the inability to change settings on a persistent service after the
first run
- the problems with multiple sites on the same host

The way we do things now is to pass these settings through
site/app/dynamic profiles which all get mashed into task attributes
(though some selection happens based on namespace). It's hard to
efficiently check if settings are different between tasks, since you
have to look at all attribute values and compare, for each task.

My plan was to make a cleaner separation. There should be site
attributes (such as jobThrottle), provider attributes (e.g. slots), and
job attributes (maxwalltime). Each would go into the corresponding XML
node. So jobThrottle would be a child of <site>, slots would be a child
of <execution>, and walltime would be a child of <application>, which
would now be defined in sites.xml instead of tc.data.

This eliminates the need for namespaces as a (poor - the name "karajan"
does not belong in sites.xml) indicator of what should go where. But the
more important thing is that once an execution provider for a site is
defined, you know that the settings for that are not going to change. So
you can use the actual instance to distinguish between different
settings. This makes it much easier to support multiple coaster
configurations.

And yes, David's configuration system makes this less relevant from a
user's perspective, but that just part of it.

So this makes FQNs an annoyance in sites.xml, so the only place where
they remain is for app names. But then we don't use them there. We name
things "cat", not "system::cat", and I have heard nobody so far trying
to use the latter. That's why I asked, but wanted to make it short.

Mihael

On Mon, 2014-06-23 at 08:41 -0500, Michael Wilde wrote:
> I don't think they matter in tc.data and sites.xml, since with the new 
> config mechanism in 0.95 these files should seldom be visible to users.
> 
> I think namespaces might more important in the language itself, to 
> support a richer package model for script libraries.
> 
> But neither is high priority at the moment.  I feel we should leave the 
> namespaces in tc and sites as-is for now.
> 
> - Mike
> 
> On 6/22/14, 7:40 PM, Mihael Hategan wrote:
> > Hi,
> >
> > What are your general feelings toward namespaces in various places in
> > swift (e.g. tc.data, sites.xml)? Do you like them? Think they are
> > necessary? Would like to see them gone?
> >
> > Mihael
> >
> > _______________________________________________
> > Swift-devel mailing list
> > Swift-devel at ci.uchicago.edu
> > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>