Jean, some comments/questions: Generally, where will the specific names for the parameters from the object cache referenced here be specified (if it's not a future version of this spec, then which one would it be)?
3.1 Mention towards the end of this section of "common methods like src, dst" but no further discussion in the document. 3.3 The table here seems to be using ARC interface classifications, but the terminology is not current. I'm also unclear as to why the SVR4 interface would be classified differently than the others. 3.4.1 What is a "data cache node" (in other words, can you be more specific about the class that this is based on the draft terminology from the Data Object Cache work)? Is the application responsible for passing it in, or does the engine do so? What about a common interface for obtaining size requirements for the bits to be installed? 3.4.3.1.2 How would the application obtain the lists of files that are referenced here? Would it make sense for the class to be able to do this itself by defining an interface that the media might provide? I'm not clear on whether, for something that looks like the live CD, there's a single cpio transfer invocation, or multiple. The file list noted here seems to indicate there might be multiple, but the use case in 3.6 seems to indicate a single one. WRT to the do_clobber functionality here, would it be a good idea to define an interface here for that specific implementation to be associated with the media instead of embedded in the class? Would it be a good idea for the dryrun to allow for copying to /dev/null rather than not executing at all? 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. Dave
