On 06.09.17 13:59, Ian Boston wrote:
package for each new conversion Oak supported, greatly simplifying dependencies downstream, especially where the source and target classes already exist. If a concrete method is used, the package will need to be versioned everytime. I suspect OSGi rules will require a minor version number increment each time, which is going to make a downstream developers life painful. In addition if an implementation bundle in Oak decides it wants to optionally support a conversion, it wont need to version the Oak API to achieve that. With concrete methods, ever change, wherever they are and however experimental will require a new version of the Oak API. This was the reason for going for a wildcard method. It allows extension without any downstream disruption, missing dependencies or out of band dependencies. I think the boils down to how much disruption Oak wants to inflict downstream to get new capabilities added, or inversely, how open Oak is to requests for API changes from downstream ?
I agree with everything said here, but there is another way to look at it too: this is side stepping backward compatibility concerns by moving from a statically typed API to a dynamically typed one effectively evading semantic versioning. This eases development and deployment but might push problems further out to production.
For this reason (and as I said before) introducing such a general API is a significant change and would deserve a discussion on its own revolving around the pure API change, mostly decoupled from the "secure URI" issue, maybe mentioning it as a use case.
