Hi Team,
Over the last couple of days I've had the recurring thought that it's over-engineering to require config namespaces in workspaces. I can understand how for the Method repository such scoping is helpful, to organize methods and potentially distinguish those with the same name (because the method repo is global across FireCloud).
But I'm hard pressed to see the value-add in requiring such scoping within a workspace, nor do I believe it outweighs the complexity added to the UI and API. For one, it's very tough to imagine a use case where you'd need to have multiple methods with the same exact name, but which do different things, in a single workspace. Doesn't that smell more like bad design, rather than something we should foster? Second, but even if one's heart is set on constructing a workspace that way, it's cleaner and simpler to just name the configs differently (in the workspace) instead of also introducing another layer of scoping into the workspace. Third, requiring namespaces to be specified for method configs clutters many endpoints in the API with an extra parameter, such as
https://api.firecloud.org/#!/Method_Configurations/updateWorkspaceMethodConfig
https://api.firecloud.org/#!/Method_Configurations/getWorkspaceMethodConfig
https://api.firecloud.org/#!/Method_Configurations/validate_method_configuration
et al. And these would in general need to be exposed in the Python and CLI bindings, too (e.g. in https://github.com/broadinstitute/fiss)