>
> Accordingly, I get bogged down in details like:
>
> @SessionId - why is this useful (compared to, say,
> std::[shared|weak]_ptr<Session>)
:/ This was a bit of a mixed implementation. The client side supports multiple trust sessions per connection, while the server does not. So [at least for now] I've removed support for multiple trust sessions (start refused). So removed the SessionId in favour of std::shared_ptr<TrustSession>
> There's a lot of this to digest - and I don't know what feature(s) it is
> supposed to support.
Thanks for the review. /docs.google. com/a/canonical .com/drawings/ d/1Sx3Q6IugYY0D jrQfN3em6PBhyeN otXtYAa4UioVdT8 c/edit
This adds/implements the API required for client & server to manage "trust sessions" (as the name suggests).
The easiest way to get an overview of what this code "does" is by looking at the diagram:
https:/
> weak]_ptr< Session> )
> Accordingly, I get bogged down in details like:
>
> @SessionId - why is this useful (compared to, say,
> std::[shared|
:/ This was a bit of a mixed implementation. The client side supports multiple trust sessions per connection, while the server does not. So [at least for now] I've removed support for multiple trust sessions (start refused). So removed the SessionId in favour of std::shared_ ptr<TrustSessio n>
> CreationParamet ers - this has one public mutable member (which trusted_ session_ trusted_ session. c
> @TrustedSession
> initializes itself). Why does it need a constructor? (And does it really
> belong in the shell namespace?)
>
> 61 + * Copyright © 2012 Canonical Ltd.
>
> Wrong year.
>
> @examples/
>
> This is written using the original (async) APIs it would probably be clearer
> using the (slightly) more recent sync ones. (I suspect cut & paste from an
> example that should have been updated last year.)
Refactored example & added sync methods to trust session API.