Dave, Thanks for the feedback, questions/comments are inline.
On 02/25/10 04:35 PM, Dave Miner wrote: > On 02/22/10 04:32 PM, jeanm wrote: >> >> Please review the design document for the transfer module of the Caiman >> Unified Design project. > > Reviewed version 2.0. > > I have a general question here. Do you feel that implementing an > IPSTransfer API that's this extensive is actually worth the trouble? > Or should the applications primarily be using the pkg.client.api > interface directly, with some add-on shims to help the application > interface with the engine? The issue I'm concerned about is that, as > pkg capabilities evolve, taking advantage of them in any application > will often (if not always) require two layers of work: here in the > IPSTransfer class, and in the application. Were we desiring to > maintain only a subset interface that was simpler than the pkg API > that might make sense, but I don't think that's true in general; both > AI and DC want (need) to access a very large subset of the pkg > functionality. Thus I'm wondering if we should re-think the approach > here. The existing transfer module for IPS pre-dates the pkg API, so > its design assumptions were very different. Maybe I'm misunderstanding you, but wouldn't having both AI and DC (for example) call into the pkg.client.api interface potentially result in code replication? Say both want to do an ips transfer of a pkg list from a known publisher. Are you suggesting that then both AI and DC would have code to do this? Or are you just suggesting that this interface be greatly simplified? Something more along the lines of what Keith suggests which involves a list of actions to be performed, default might be something like [image-create, set-publisher, install]. > > 3.3.1 > MediaTransfer has add_arg, others have add_args > IPSTransfer has two set_type's and no get_type I've removed add_args due to your below comment. It was basically a convenience function that just didn't add any convenience. Fixed the two set_type's typo. > > 3.4.1.2 > Should _src_mntpt and _dst_mntpt be merely source and destination > directories? Seems that mountpoint is overly specific. Changed. > > 3.4.1.2.6 > Are these allowed to be both files and directories? Yes they could be. Text added that now makes that clear. > > 3.4.1.3.10 > My concern with add_arg() is that it's somewhat non-deterministic; > you've documented what the default options currently are, but if we > decided to change that default, then add_arg may or may not achieve > the desired result. I think it's safer to put the burden on the > application to provide a complete, coherent argument set should it > require this level of customization. > As stated above, removed. > > 3.4.2 > Ignoring the general question that I led off with, a few comments on > IPSTransfer (though I'd probably have more were that question not > looming). > > I believe you and Sarah are discussing this, but being able to consume > a .p5i is desirable/required. Yes. But as you state, this has the big looming question of IPSTransfer's existence in it's current form or at all. > > 3.4.2.2.1 (and 3.4.2.2.2) > With auto-configuration from the repository URI, is there a reason to > require the dict rather than just using a URI? You're right, I don't think there is. > > 3.4.2.2.3 > What would _ips_args potentially contain? Things like update_index, verbosity, refreshing of catalogs was what I was thinking. > > 3.4.3 > What are the use cases that lead to including the translate > functionality? I guess I don't really have one, it was more for predicting what people might want in the future. So I will remove it, if people desired such functionality in the future, it could easily be added. Jean
