Client API philosophy
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@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
Re: Client API philosophy
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... 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@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
Re: Client API philosophy
BTW, I do actually agree with half of your points. Just feel that over-generalising in a discussion like this one is counter-productive. Because it always is (<- over-generalisation). On 10/11/14 11:31, Daniel van Vugt 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... 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@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
Re: Client API philosophy
On Mon, Nov 10, 2014 at 2:31 PM, Daniel van Vugt 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@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
Re: Client API philosophy
We frequently disagree on the measurement criteria :) Also, IMHO code reviews provide a more structured place for targeted discussions. And that helps to focus on facts, with less hand-waiving. On 10/11/14 12:10, Christopher James Halse Rogers wrote: On Mon, Nov 10, 2014 at 2:31 PM, Daniel van Vugt 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@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
