Hey hey,
my concluding thoughts follow:
So, to summarise what I am advocating:
- Where we can define a good generic core API, this is the preferred approach instead of plugin-to-plugin communication.
- In other cases we might acutally be looking at a new plugin type. (Another recent example is question bank columns MDL-40457 - should that have been a new plugin type?)
- But, in other cases where direct plugin-to-plugin communication lets us implement some useful functionality today, than a core API that would be too hard or prohibitively expensive to implement now, then it should be allowed (with an understanding that we might want to re-design to a core API in future, when we work out how).
RE:
Point 1: This is Dev world-confuses me....shall leave those matters to those who know more. (I think the last two posts have squared a good argument for this point, here).
Point 2: I think this is your world Tim: Expert -ADVISE Eh? This is your bag.
POINT 3: We have some synthesis of thought here, e.g. As I said earlier:
it may be that time is a key factor in applying a one-rule to all features and what-not....identifying a timeline for those features concerned with regrd to API changes....might enable the more succesful/used features to be affected after seeing how things work with less-used features....I guess I am suggesting a roll-out for change as opposed to a fast-blanket change.
D