Client API philosophy

[Christopher James Halse Rogers]

On Mon, Nov 10, 2014 at 2:31 PM, Daniel van Vugt 
<daniel.van.vugt at canonical.com> wrote:
> Definitely controversial; factually false or easily arguable.
> 
> Sounds like a response to one of my merge proposals. So please put 
> arguments in the code reviews...

It indirectly is, but also in response to some discussion on IRC of one 
of your merge proposals.

I thought it would be valuable to work out what top-level philosophies 
we agree on and discover where we differ. Code reviews make a poor 
venue for this, as they're not as visible and are primarily concerned 
with the concrete code under discussion.

If we disagree on the measurement criteria it's very difficult to reach 
consensus on the code :)

> 
> On 10/11/14 10:48, Christopher James Halse Rogers wrote:
>> Hey all.
>> 
>> We're getting into the meaty bit of client API support I thought I'd
>> write some things about API design philosophy to see if they're
>> controversial.
>> 
>> *) An API with lots of functions that do one thing each is simpler 
>> than
>> an API with few functions that do different things depending on other
>> state.
>> 
>> *) A function with unclear semantics is harmful
>> 
>> *) Mir will not have an external reference for window management 
>> policy.
>> Window management semantics will be associated with the API. There 
>> is no
>> equivalent for 
>> http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html
>> outside the client API documentation.
>> 
>> *) The client API should be implementing policy, not mechanism.
>> 
>> *) Where state transitions are allowed, it should be possible to
>> transition from one valid state to another valid state without
>> temporarily being in an invalid state.
>> 
>> Some thoughts.
>> 
>> 
> 
> --
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/mir-devel