On Oct 18, 2013, at 7:52 AM, Uri Shachar <ushac...@hotmail.com> wrote:
>> cheers, >> James > > +1 with a couple of suggested add-ons: > > 1) New API should be > committed into experimental.h and moved into ts.h after a couple of > weeks (3-4?) - this should be compulsory for API which didn't follow > this new process, and encouraged for API which has. > The goal is to give a bit more time for comments before we commit ourselves > to supporting the API for a fairly long period.... > Frankly > - I like experimental.h - even though it is a bit of a cruft bucket. As > long as the cruft is limited to the API layer, cleaning it up > occasionally seems like a fair price for maintaining flexibility. experimental.h should be cleaned out, it’s mostly legacy stuff from various customer specific additions. I moved a bunch from it to ts.h a long time ago, but left some which I didn’t know what to do with. Also note that IMO, it’s ok to add additional experimental include files as appropriate, as long as we migrate them to remap.h / ts.h or whatever frozen includes that we have, once finalized. Igor: The point of “experimental” include files / APIs would be that yes, they are “free for all”, you can break them / modify them at any time. The idea would be to make the APIs available for others to use / test, but not deal with the backward compatibility clause. Maybe it ought to be #include <ts/experimental/some_api_feature.h> ? > > 2) Adding a suggestion for new API to be integrated into a sample plugin - > giving users a good sample to copy. +1. One caveat though; there might be cases where a new API is very reasonable, and goes through reviews etc., but the original author might not be able to disclose / share the plugin that is her specific use case. Do we require them to make a “dummy” plugin for that? That seems a little wonky, but it would fit into the “examples” plugin directory to have such plugins which don’t do anything useful. — Leif
