[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