>>>>> "Pete" == Pete Fotheringham <[log in to unmask]> writes:

    Pete> 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?

    Pete> Sam

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

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


So, when I got to my office this morning, Kevin was waiting with a bunch
of questions about this design.
We had a bit of a discussions and he pointed out a number of things.

First, let's separate the discussion of RPC boundaries from class
boundaries.

It's not actually necessary to have an RPC boundary to have different
storage backends.  You simply need to have an abstract interface and be
able to instantiate multiple storage backend objects.

We don't even need loadable storage backend plugins: we'll know at
compile time what storage backends we need.  We do need a well defined
abstract interface. That could just as easily take the form of a .h
file, vala objects as it could an RPC.

Second, the single RPC boundary doesn't actually stop you from having
headless operation. On Linux at least you can have a program that
optionally pops up UI only when needed; doing so without opening a
connection to the X display when no UI is required is a bit involved but
certainly possible.

I don't know if that's true about Mac and Windows, but you could just as
easily share a bunch of code and start either the headless or
non-headless version of the moonshot identity process if your OS doesn't
support the idea of a process that only sometimes generates UI. However,
I'm fairly sure that both on Mac and Windows you can have a process that
optionally generates UI.

Also, Kevin reminded me of a future goal of the library. One of the
items dropped from the first SOW and not added to this SOW was an RPC
interface that isolated applications from usernames and passwords. The
goal of that RPC was that the identity application would never expose a
password to an application (although applications could expose passwords
to the identity app). INstead, the identity app would directly generate
EAP tokens.  That is still on our long-term radar. The design
implications today is that there needs to be a place to run core code
independent of the storage server and application.  I guess that could
be in some library that always gets linked into the storage server,
although it seems more natural for it to be in an app that houses the
core logic, optionally the UI and the storage server.

I was not previously aware you were considering a design where the UI
ran in-process with the application.  That can't work. There is a hard
abstraction (the GSS-API, RFC 2743) between Moonshot and the rest of the
application. We cannot ask applications to change except through
changing the GSS-API through a standards process. Even if we do change
the GSS-API, we have to support existing unchanged applications;
backward-incompatible changes are not on the table. That abstraction
does not permit us to ask an application to present UI, and even if it
did, we would not control the UI presented.  So, in effect you're asking
to present UI as part of a library call without the application's
cooperation. You can technically do that on Unix: you can start up your
own display connection and main loop in the library. There are a lot of
disadvantages to doing this. I don't know if GTK uses X or is more
native on the Mac; if it is more native there then it's probably not an
option at all.  Based on what I know of COM threading models, my guess
is that Windows does not expect libraries to pop UI except through well
defined interfaces like COM or .net with the cooperation of the
application.  Even if you can do it, there are significant build and
deployment concerns I have with linking GTK into arbitrary Windows
applications.
So, I don't think  in-application UI is something we want to do.

In conclusion, I don't see the need for more than one RPC boundary. I do
see a need for non-storage-server code running outside the application,
at least in the future. I think an identity selector app that houses the
storage server, and when needed the UI component makes sense as a
design, but that's just a guess. No in-application UI is a hard
requirement and one RPC boundary is a very strong desire.