[Swift-devel] FQNs use in Swift

Mihael Hategan hategan at mcs.anl.gov
Mon Jun 23 12:10:10 CDT 2014


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.




More information about the Swift-devel mailing list