On 06/12/2011 22:36, Sam Hartman wrote:
>>>>>> "Pete" == Pete Fotheringham<[log in to unmask]>  writes:
>
>
>      >>  2) You can't lose the existing libmoonshot interfaces. I mean you
>      >>  can change their call signatures or names if you like, but the
>      >>  functionality of a client application to select an identity with
>      >>  possible prompting is required. That's kind of a major use case
>      >>  of the system. So, your architecture needs to describe how the
>      >>  interactions between the application and the UI are handled. This
>      >>  is presumably either through the identity server or another
>      >>  library.
>      Pete>  Agreed. Modified the text and the diagram to address this (I
>      Pete>  believe).
>
>
> How does this interact with the Mac design?  One of the advantages of
> keychain on the Mac was that it avoided DBUS.  What RPC are you using
> between the UI and the app on the Mac then?

Sam

Thanks for your input - getting to the 'right answer' is a lot easier 
when ideas can be bounced off other people.

In the initial implementation, the RPC boundary is between libmoonshot 
and the app, moonshot-ui. That doesn't allow a: different backend stores 
or b: client apps accessing identities without any UI - hence the 
refactoring.

In my proposed change, the RPC boundary is between identity-manager-lib 
and identity-storage-server. All the UI would happen in the calling 
application's process. This would achieve the primary goals of the 
refactoring in abstracting the data store and UI interfaces. A 
disadvantage is that a lot of the existing code would have to be moved 
and changed. An advantage would be that, on Mac at least, we could, if 
we uses the Keychain for storage, get rid of the need for RPC via DBus.

An alternative approach (shown in the diagram at 
https://gitorious.org/petefoth-public-docs/petefoth-public-docs/blobs/raw/master/Moonshot/Alternative%20Proposal.jpg) 
would leave the upper layers mostly unchanged:

identity-manager-ui-lib (replacing libmoonshot) provides the 
(in-process) InstallIDCard and GetIndentity APIs to client apps that 
need to interact with the User. It communicates via RPC with 
identity-manager-app.

identity-manager-app  (which us the renamed moonshout-ui) uses the 
function-call API provided by identity-manager-lib to store changes.

identity-manager-lib is a new component which provides in-process APIs 
to identity-manager-app and to other client apps which do not need to 
interact with the user. It accesses the store using the 
identity-storage-server:
    * on Linux and Windows using RPC as in the current moonshot-ui;
    * on Mac, either re-using the DBus implementation, or using a small 
library wrapper round the Mac Keychain.

I prefer this alternative for a few reasons:
1: It minimises code changes in the higher layers (libmoonshot, 
moonshot-ui) although their names will change to reflect more clearly 
what they actually do;
2: All the Moonshot related UI happens in a single process, not in the 
processes of all the client applications;
3: It still meets the primary goals of the refactoring in abstracting 
the data store and UI interfaces;
4: It feels like a better architecture :-)

It does mean that we will still need DBus in the Mac implementation. 
(And if we use DBus for the interface between 
libmoonshot/identity-manager-ui-lib, moonshot-ui/identity-manager-app 
then we may as well use it for the identity-manager-app - 
identity-storage-server interface as well, rather than implementing a 
Mac Keychain backend.)

What do you think?

Regards

Pete
-- 
Pete Fotheringham
Codethink Ltd
http://codethink.co.uk
+44 7740 351755