On Apr 29, 2013, at 12:39 PM, Dina Schneidman <">duhovka@gmail.com> wrote:
I should be a little clearer. There are two separate questions: 1) whether code to do conversions should be available to existing code 2) whether the code should be available as part of the supported IMP API (eg should it be in the documentation as non-deprecated and something we support for users outside of the repository) There is (and should be) a lot more of 1 than 2 in any project, including IMP and there are lots of ways that we can provide 1: - public API - examples - via internal APIs for code in the IMP repository Clearly, we need to make sure that existing code isn't broken badly. But we don't want to have things in central places in the IMP API simply because there are useful/used somewhere. The code being their imposes real costs, this discussion being an example. General guidelines that I have seen are for what should be in an IMP tend to include, most importantly 1) can't easily be implemented by someone on top of functionality we already provide but also 2) form coherent chunks of functionality 3) are, or are believed likely to be, widely used
|