On 02/25/10 05: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.
I'm biased of course, but I agree with Dave. You're going to be duplicating a significant amount of material if you wrap the pkg(5) API again with another API. There's also some things about the wrapper you've proposed that really aren't the right mapping or translation of the pkg(5) client API. In particular, many of the interfaces for publisher URIs have been simplified too greatly and assume 1:1 mappings. The only things that should be part of the caiman transfer module related to pkg(5) is anything that is specific to caiman and pkg(5) operations. For example, parsing of any special configuration files it uses, or ensuring that the default logger object that the pkg(5) client API sets up is replaced with your own. If there is missing functionality in the pkg(5) client API that you need, please open bugzilla entries for them and we'll do our best to get them evaluated and implemented. Cheers, -- Shawn Walker
