On 02/26/10 03:11 PM, Karen Tung wrote: ... > On 02/23/10 02:44 PM, jeanm wrote: ... >> On 02/22/10 05:47 PM, Karen Tung wrote: ... >>> - There's no discussion about how, if any progress will be reported >>> back to the caller of >>> the transfer module. Does the caller pass in a callback function? >> I'll be using the logging module that Sanjay and Ginnie are in the >> process of designing. >> I've talked with Sanjay and there shouldn't be a callback function but >> there will probably >> need to be an additional attribute to hold the logging object. I'll >> add that into the spec. > Not sure whether you need to add an attribute to hold the logging > object. You can always > get the logging handle from the engine. After I flush out the details on > how to get it from > the engine, you can include that info.
You can always the logger module itself with logging.getLogger(<logger_name>). However, if you have any special log handlers and want to be able to remove them, you have to keep a reference to the their handles. >>> - There's no discussion about how to interrupt a >>> transfer-in-progress. This functionality >>> is required when people choose to quit the installer in the middle of >>> a transfer, which could >>> be a long process. >> You're right. I'm not sure exactly what section that belongs in, >> overview??? I believe we would want >> to catch the KeyboardInterrupt and exit. > I don't believe catch keyboard interrupt and exit should be done in the > transfer module. > Catching the keyboard interrupt and determining what to do should be > part of the application's > job. What I am talking about is an explicit function that the engine can > call to immediately > stop the transfer-in-progress. The "tm_abort_transfer()" function in the > existing > transfer module provides the kind of functionality I am talking about. The approach we took with pkg(5) was to catch KeyboardInterrupt if we needed to perform any special cleanup or other error handling and then re-raise the exception afterwards. That allows clients to do whatever they want for that specific case and allows the underlying API to do anything it needs to as well. >>> section 3.4.2.2.5: >>> - Why we need an alternate root. Isn't that the "destination" >>> directory? If so, I think calling it alternate root is confusing. >>> Furthermore, this >>> should be a required attribute. Default value of "none" won't work. >> Actually it's not required. This is equivalent to the -R option when >> you run pkg. If it's not >> present, then the operation is done on the image discovered >> automatically. > What do you mean "image discovered automatically"? When using the CLI, it will start with the current working directory and then work its way down trying to find an image automatically. However, API consumers are required to provide the location of the image, and can control this behaviour, so this doesn't really apply (since you'll be using the client API). Cheers, -- Shawn Walker
