[Swift-devel] FQNs use in Swift

[Michael Wilde]

This all sounds good, so best to keep going.

But regarding maxParallelJobs and initialParallelJobs, lets keep the 
names in sync with 0.95.

There we used the term "task" to indicate a Swift function invocation 
(usually an app task) and "job" to mean a site resource manager job.

- Mike

On 6/23/14, 12:10 PM, Mihael Hategan wrote:
> On Mon, 2014-06-23 at 11:00 -0500, Michael Wilde wrote:
>> 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?
> I was asking myself the same question. Initially, I wanted to allow both
> old and new configurations, and translate internally, but I believe that
> would make the code messy for what is essentially a one time operation
> for a limited number of users (due to the new config mechanism)...
>
>>    My inclination would be
>> to provide a tool to convert sites.xml + tc.data into the new config
>> format, and urge users to convert.
> ... so I reasoned that we could do just what you say above.
>
>> Whats the development time needed for this?
> Small-ish. I did most of it yesterday. I was under the impression that I
> was fixing the coaster stuff, but it led me here. Let me stress again,
> the coaster stuff really needs fixing. This is, to me, acceptable
> collateral damage.
>
>> Will it make code maintenance and enhancement easier?
> That's my take on it, although that code isn't touched much.
>
>> 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.
> I was thinking about that too. It is related in that provider properties
> are now separate from other task properties, so it would be easier to
> add some API to get a list of what each provider supports and to use
> that to validate sites files without having to keep a separate account
> of provider properties.
>
> Mihael
>
> PS: While we're at it, jobThrottle and initialScore are being "replaced"
> with maxParallelJobs and initialParallelJobs.
>

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