>>>>> "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.