Hi Karen - thank you for the feedback. My responses are in line. ginnie
On 02/15/10 17:15, Karen Tung wrote: > Hi Ginnie, > > Here are my comments: > > - Section 3: > * What does "enable components of the installer to log data without > the overhead of output" mean? What I meant by this was the logging framework should hide the complexity of logging to different formats or logging different levels of output to different locations from the components. > > - Section 4: > * I think "log levels" as a type of "event filter". How is it different? These aren't really event filters. The logging handlers will be the event filters. I'll be sure to clarify this in the revision. > > - Section 5: > * General comment about this section. All the requirements are listed > here, but there's > no further explanation on the requirements, and there's also no other > section in the > document that explains why the specified interfaces provided are > sufficient to satisfy > all the requirements. I'll address this and be more specific. > > * 2nd bullet: Remote logging is enabled by default". Not sure whether > this is possible. > To log remotely, I imagine that we need to have network access, and > also need > to set it up somehow, can it really be enabled by default? What will > the behavior > be if there's no network connection? I'm removing this as a requirement. > > * 3rd bullet: Since using Python logging is not decided yet, I think > it is sufficient for > this bullet point to say that the logging framework needs to provide both > a Python and C interface. The way it is presented now implies that > Python will be used. Thanks that's a good point. At the time we were not sure what the interfaces would be. They will be python interfaces. I'll clarify that. > > * 4th bullet: The 3 sentences here sounds to be like 3 different > requirements. Why not > let each of them have it's own bullet? Ok. > > * 5th bullet: For remote logging, does this mean that the logger will > write to the target > directory of the machine with the specified IP address? I think we > need to capture what kind of setup the remote machine need to do in > order for this to work somewhere in this doc. Yes. I agree. I'm working on a server side component for the revision. > > * I am not sure what does "The logging framework allows the user to > modify logging level from the command line" > mean. The user would use a CLI to locate the components of an application and to modify the logging level of a particular component from the command line. I'm not sure, given the conversation we had that this will be managed by the logger. Most likely not. I'll address this point when I revise the doc. > > * It is not discussed in this section, or anywhere else in the > document. Will the logging > framework allow other types of logging handlers be registered, or only > the implemented ones > can be used? Any logging handler requested by the application/engine can be used. > > -Section 6: > * For all the interfaces, it would be useful to indicate what is the > expected type for the input, > such as "string/int/object"...etc.. Also, which input is required, and > which is optional. > If it is optional, what's the default value? Ok. I'll be sure to be more explicit. > > * section 6.1, can 2 loggers be instantiated at the same time by a > single application? No, only one logger is instantiated per application. There can be multiple handlers. > > * section 6.2, What's the purpose of this function? Find_Component is would be used to locate the components of an application to modify the logging level of a particular component from the command line. Given the conversation we had, I'll probably be modifying this. > > * section 6.3: I am also not clear how this function would be used. > It would be good to > provide more details. Ok. I'll flesh this out more. > > * section 6.4: Looks like there's no optional/required argument to the > actual logging > functions to indicate which component is generating the messages. Do > callers have > to manually add that to the message before calling this function? This would be handled by the Register_Component function (6.3). > > > - Section 9: > * I am not clear what use case 2 is for. Is it for a user to easily > retrieve some specific > content of the log file? Or is it that the user only wants certain > type of output, > so, he/she specify that while calling the application. The > application in turn calls > the logging framework with those filters. I need to modify this based on a misunderstanding I had. Thanks for pointing this out. > > * Section 10: > - This picture shows that the application is the one that instantiates > the logger. > My understanding based on Sarah's caiman design document is that the > logger > is instantiated by the execution engine. Then, the application can > request to > get a "handle" on the logger. The same handle will be passed onto > each of the checkpoints > registered in the engine. That way, we ensure the application and all > the checkpoints > that are registered to run by the application all use the same logger. Thanks. I'll correct this. > > - What's the "XML Manifest" for? The diagram was meant to be a more generic representation of the more specific examples in the architecture document, so I included it for completeness. > > Thanks, > > --Karen > > On 02/09/10 10:21, Virginia Wray wrote: >> Sorry about that. It completely escaped my attention that external >> folks would not see it. >> Now also posted here: >> http://hub.opensolaris.org/bin/view/Project+caiman/Logging >> >> Thank you for bringing this to my attention. >> -- >> >> Ginnie >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20100224/b28b4638/attachment.html>
