Code review comment for lp:~unity-team/platform-api/devel-for-qtmircompositor
Revision history for this message
| Daniel d'Andrada (dandrader) wrote | # |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
> Few things:
>
> 1. If we can avoid breaking ABI, lets avoid breaking ABI. Please lets just add
> new functions for window event handling in addition to the existing input
> event ones, just mark them as deprecated in their comments. Not a big
> commitment to ABI stability, but in this case it looks relatively easy to
> *not* break it.
And what are we gaining by keeping ABI compatibility? We are the sole consumers of platform-api currently, thus I don't see any real gain.
But I do see a big drawback of keeping ABI compatibility in this MP, which is ending up with clunkier API.
Take mir as an example: It's constantly breaking its API and ABI because it's a new project that is rapidly and constantly evolving. Freezing its API so early would severely hamper its evolution. I see the same for platform-api, as it's a thin wrapper of mir & others. It's an illusion to think you will get the API right right off the bat. So it's a moot point to enforce ABI stability right now IMHO.