All good ideas. This has been informally discussed amongst some of us.
toggle quoted messageShow quoted text
For example, how does the SAL provide a common layer of abstraction but
then the user be able to explicitly access the non-commonly-abstractable
functionality of an underlying SB ...the same can be said of any service.
The extensible model concept proposed by the SAL should address large
swaths of this, but I don't think EVERYTHING falls under tha umbrella
...so, ...yeah ...all that.
On 7/18/13 3:57 PM, "Chris Wright" <chrisw@...> wrote:
After the recent round of project proposal reviews I'm wondering about
APIs and whether we need to include any API review at some stage in the
lifecycle or release process.
Things that I think are important are:
1) Identifying the APIs. This is largely just documenting what is there
to help developers.
2) Making APIs consistent. Following some fairly predictable patterns.
CRUD helps, but more eyes on what resources and attributes are exposed is
probably a good thing.
3) Making APIs that are not overlapping. Ensuring that we have unique
ways to access controller resources could require some cross-project
coordination or review.
I'm looking for feedback on whether folks agree that reviewing the APIs
is something that the TSC should take one? And then, if so, specifically
where in the process?
TSC mailing list