[Swift-devel] FQNs use in Swift

[Michael Wilde]

OK, I see what you want to do here, and why.

What you're proposing will make the internals cleaner, and would be a 
chance to harmonize the user-visible and internal property names.

If we do this now, in trunk, presumably 0.96 will have the new names.  
So that would put a stake in the ground for conversion or all users to 
the new config mechanism.

What should we do for backwards compatibility?  My inclination would be 
to provide a tool to convert sites.xml + tc.data into the new config 
format, and urge users to convert.

Whats the development time needed for this?

Will it make code maintenance and enhancement easier?

Currently, finding property values (eg, within provider code) has been a 
surprisingly large obstacle to provider enhancement and support. If this 
fixes that problem (which also requires developer documentation) it will 
be worthwhile, if its affordable.

- Mike




On 6/23/14, 10:14 AM, Mihael Hategan wrote:
> 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
>

-- 
Michael Wilde
Mathematics and Computer Science          Computation Institute
Argonne National Laboratory               The University of Chicago