Merge lp://qastaging/~vanvugt/mir/super-simple-connect into lp://qastaging/~mir-team/mir/trunk

I suspect someone will complain about reinterpret_cast. But consider the alternative with N callbacks (one for each API function) and each having to contain its own:
   *(static_cast<MirSomething**>(context)) = something;

I prefer the reinterpret_cast.

PASSED: Continuous integration, rev:500
http://jenkins.qa.ubuntu.com/job/mir-ci/80/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-quantal-amd64-ci/81/console
        deb: http://jenkins.qa.ubuntu.com/job/mir-quantal-amd64-ci/81/artifact/work/output/*zip*/output.zip

Click here to trigger a rebuild:
http://jenkins.qa.ubuntu.com/job/mir-ci/80/rebuild

This is pretty much what I was thinking of doing - although I was was going to prefix with "s" not suffix with "_sync", and wasn't going to use reinterpret_cast.

> This is pretty much what I was thinking of doing - although I was was going to
> prefix with "s" not suffix with "_sync", and wasn't going to use
> reinterpret_cast.

Oh, and I was going to use a separate header.

i like it. slight preference for suffixed names (as it is), no reinterpret, and a separate header

It's true that making up new words like "sconnect" is one way to avoid ambiguity. But it steepens the learning curve. Another possible convention is "mir_connect_now", which is a clear message to the reader that "mir_connect" might not connect /right now/.

Separate headers? I disagree. This function relates directly to the existing contents of mir_client_library.h. Separate headers would also steepen the learning curve and it would be generally bad design to have a "connect" function in a different header to its requisite disconnect function.

> It's true that making up new words like "sconnect" is one way to avoid
> ambiguity. But it steepens the learning curve. Another possible convention is
> "mir_connect_now", which is a clear message to the reader that "mir_connect"
> might not connect /right now/.
>
> Separate headers? I disagree. This function relates directly to the existing
> contents of mir_client_library.h. Separate headers would also steepen the
> learning curve and it would be generally bad design to have a "connect"
> function in a different header to its requisite disconnect function.

To clarify: I'm not blocking your approach. Just that I would have defined smir_connect(..) and smir_disconnect(..) and the rest of a synchronous API in a separate and independent header.

Looks good to me. I think *_sync is better than s* (it's more clear what "sync" means over "s") and don't see a need to use another header file.

Another +1 for *_sync vs s*.

I'm not averse to having a separate, synchronous, header, but I think that as long as we maintain the convention of having _sync stuck on the end of anything that can block it's not particularly necessary.

If you call mir_connect_sync, it's pretty clear you don't want asynchronous behaviour, so I don't think we need to segregate the sync calls out for client's safety.