Though maybe the internal re-work could be separated into a follow on project, a common data source api could still use the current internal mechanism.
That's what I would do for an initial impl.
I think the only question is whether they are a good idea or not: if they are a good idea then making the changes now in this release is very desirable to avoid future changes in the network client. Surely it should be possible to evaluate reasonably quickly whether the changes result in a simpler and improved user experience. As you may have guessed, I think they do :-)
Not sure how we would evaulate quickly, I'm not convinced the scheme is easier and it may be more confusing to users.
The other issue is do we hold up releasing 10.1 and the derby client to resolve this? Especially as we don't have any actual code or patch implementing it. How long would we wait and how does that tie into release early, release often?
Well, there is a strawman in the branch and we've not been discussing it long.
And that brings me to one solution, release soon without this change (as it doesn't exist), release once it does exist, and then let the users tell us which approach is better. Covers release early/often and the darwin aspect of open source.
Early implementation is one thing, but you want to get the public interfaces right, or at least easily extensible, from the start so you don't end up regretting something forever.
This is new functionality that was dropped into the project and questions were raised fairly quickly. Rushing out a first release (and hence committing to an API) without clear answers does no-one any good, neither users nor developers.
-- Jeremy
