Stephen Hahn wrote: > * Shawn Walker <[EMAIL PROTECTED]> [2008-09-08 22:40]: >> Stephen Hahn wrote: >>> * Shawn Walker <[EMAIL PROTECTED]> [2008-09-07 23:46]: >>> >>> A history should be an object. (I can say this, just based on how >>> different history.py looks from everything else.) >> History is an object -- a module object :-) >> >> It's a recommendation from one of the authors of Python (Alex Martelli), >> that you can find in the Python Cookbook, recipe 6.16, "In most cases, you >> don't need either of them [singleton or borg]. Just write a Python module, >> with functions and module-global variables, instead of defining a class, >> with methods and per-instance attributes." >> >> Specifically, it was to avoid having to pass an object around everywhere. > > Hmm. I hate recommendations like these--it's a language-specific > possibility, but ith at most limited execution benefit; I think > attaching the History to the Image would be preferable.
After pondering what Tom had said, I had reached the same conclusion earlier this morning. I had originally intended history to be able to be used outside the context of an image, but it has become apparent that it would be of limited utility anywhere else. As such, I'll be making this change later today. The only disadvantage to this is that it does mean that we'll have to pass around the image object in several places we didn't before (eventually). Still, that's preferable over having to pass around a special intent/history object. >> I called it Successful because I'm a failure at naming things :-) >> >> The idea behind the boolean was to let the user know from a high-level >> whether an operation was successful while still showing the actual exit >> code in parentheses for the morbidly curious. >> >> I have no preference as the presentation of this value and I am open to >> suggestions. >> >> As for a known set of outcomes, what did you have in mind? > > I would rather have outcome, with values like: > > "succeeded", "cancelled" (from your next reply), "failed-constrained", > "failed-transport", "failed-storage", ... These could be split into > outcome and reason. Or something like that. That seems reasonable enough. I actually like that a great deal more than what I have now. I'll see what I can do to transform it appropriately. >>>> Change Summary >>>> ============== >>>> * Implemented new history module to support the storage information >>>> related to operations that modify an image and to support better >>>> post-mortem analysis. >>>> >>>> * Stores each history entry in an XML file in the new /history directory >>>> under image.imgdir. >>> Umm. I didn't expect XML to sneak in here; if it must, where's the >>> DTD? >> I didn't see the need for a DTD as it was strictly for an internal format. >> >> My gut feeling was to use json was it was a simpler, more efficient format >> that is a bit more "user readable" but that would require an OSR and extra >> libraries, etc. > > Okay. I would at least like a text file in doc/ describing the > internal history format. I will do that. -- Shawn Walker _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
