>>>>> "Pete" == Pete Fotheringham <[log in to unmask]> writes:
Pete> On 07/12/2011 12:56, Sam Hartman wrote:
>>
> 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.
Pete> I think the problem is that I have been looking at
Pete> re-architecting all of the client software - libmoonshot,
Pete> moonshot-ui, moonshot_webp - and how its components interact,
Pete> whereas what is wanted is mostly just improving the
Pete> architecture of the Identity Manager app (moonshot-ui).
Pete> If that's the case, then I don't think we need to spend any
Pete> more time on my proposed changes to the overall architecture,
Pete> as they have clearly missed the point :-(
Pete> We just need to reorganise the code in moonshot-ui into
Pete> classes which give a better separation between UI, core logic
Pete> and storage.
I believe that's sufficient.
When I reviewed your original proposal I was thinking the same thing you
were: why involve the UI component if you aren't needing new UI; just
talk to a storage server. Also, because you have fairly large latitude
in your contract, I was simply evaluating for "would it work," not "is
there a simpler way." I do think reorganizing the classes and having
clear rules like:
* Code above the storage server boundary may only manipulate the storage
server through a well defined set of interfaces
then that should be fine.
I don't have the SOW in front of me. The rearchitecture item does not
call for multiple storage server backends. I don't remember if the SOW
calls out Mac Keychain as something to implement now or simply something
to prepare for. If something to prepare for rather than implement now,
then no, we don't need multiple backends in this version.
Obviously, though, confirming an interface like this is good is much
easier with multiple objects.
--Sam
|
