Hi Ginnie, Here are my comments:
- Section 3: * What does "enable components of the installer to log data without the overhead of output" mean? - Section 4: * I think "log levels" as a type of "event filter". How is it different? - 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. * 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? * 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. * 4th bullet: The 3 sentences here sounds to be like 3 different requirements. Why not let each of them have it's own bullet? * 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. * I am not sure what does "The logging framework allows the user to modify logging level from the command line" mean. * 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? -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? * section 6.1, can 2 loggers be instantiated at the same time by a single application? * section 6.2, What's the purpose of this function? * section 6.3: I am also not clear how this function would be used. It would be good to provide more details. * 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? - 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. * 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. - What's the "XML Manifest" for? 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/20100215/a6162764/attachment.html>
