On 03/18/10 04:45 PM, Dave Miner wrote: ... > 3.4.4.2 > I'll re-express here the concern I had with the first draft, which is > that any parameters you specifically define here are potentially > duplicating (and thus potentially diverging from) portions of the pkg > API. Would it make sense to instead expose access to the pkg > ImageInterface (or any other classes) and allow the application to > directly manipulate properties of those classes? I haven't spent much > time looking at the specifics to see if this would work or not, but it > seems important to consider.
I've looked over this too, and would also note that some things are hard to interpret at the moment. For example, the pkg(5) API doens't support both removing and installing specific packages in a single operation. The "preferred" publisher bit also doesn't allow for the fact that pkg(5) now supports ranking of all publishers. That is, you can control the search order that's used when determining what package to install among multiple publishers. It also doesn't account for publisher stickiness, and it isn't clear whether it accounts for origins and mirrors either. If you want to try to make this more generic, I think what you have to do is provide an interface for callers to get an ImageInterface objece based on engine params, etc. There's really no point in having the execute wrapper for the pkg(5) case or the get_progress_estimate(). If you feel that you must have the consistency in interface, then I'd suggest that execute just calls .execute_plan() on the ImageInterface object you originally returned to the caller and does whatever special things it needs to, and that get_progress_estimate() a similar wrapper. I feel strongly that the data cache node approach is unlikely to provide callers with the level of flexibility they could have if they just use the pkg.client.api. -- Shawn Walker
