Hi Sarah - Thank you for the feedback. My responses are in line. ginnie
On 02/15/10 17:15, Sarah Jelinek wrote: > Hi Ginnie, > > This looks good. Some comments/questions... > > Design Requirements: > >> Remote logging is enabled by default. > > Why is this a design requirement? It no longer is. That does seem unreasonable. The application can determine whether or not to enable remote logging. > > >> Required input from the application to the logging framework: target >> for log location, application identification, and if logging >> remotely, an IP address. > > I would think that the input would include the possibility for > multiple target locations? Or, are you assuming one logger object per > location? Yes. It will. It won't be one logger per location. It will be one handler per location. I think the architecture document may need to be revised to reflect this. Instead of add_logger(), remove_logger(), retrieve_loggers, the functions would be add_handler(), remove_handler, retrieve_handler. > >> The logging framework allows the user to include/exclude different >> components from a logged process. > > how do you envision this working? And, what is driving this design > requirement? It doesn't seem a requirement to me to allow users > inclusion/exclusion of different components from a logged process. The > logging, it seems to me, is up to the individual component. Perhaps > there are exported interfaces that allow the user to turn off logging > for a specific component, but that isn't a function of logging, it is > a function of the component. This was a misunderstanding on my part. I'm removing that from the design document. > > Section 6.1 > We don't need an 'instantiate_logger' method. This will happen by the > application calling add_logger() on the ExecutionEngine. No specific > instantiate method is required, this is simply a function of object > instantiation. Actually, we will have to create a logging instance, which can be done via the open() function. Then we will call add_handler() to create different handlers to manage data. > >> IP address - provided for remote logging > > So, can this be a hostname as well, in case we can resolve it via DNS. Yes. It can be either. >> Types of Logging ? the logging handlers to instantiate. Types of >> handlers include file, > stream, HTTP, Progress, as > well as future handlers that may be implemented. > > So, what is a Progress handler? We have progress receiver class > defined in the architecture, which receives input from the > ExecutionEngine, which has received input from checkpoints to manage > progress. It is unclear to me what a Progress logging handler would be > used for. Can you clarify? We should talk about this more. I was thinking that providing progress updates was another type of report that would be handled by logging. > > >> 6.2. Find_Component >> An introspective method that returns the components that comprise a >> specific application. >> Input: the application >> Output: the components for an application >> 6.3. Register_Component >> Register a component with an existing Logger instance. >> Input: component ID >> Output: the Logger Instance of the application or Failure > > > What are the above two methods for? Why do we need to do this? Given a conversation I had with Karen and Sanjay, these will probably be removed. > >> 6.5 Terminate_logging > > I would think that a simple remove_logger() on the ExecutionEngine > object would terminate that logging for an application. Yes. that would work. > > > The diagram you have page 7 shows each component logging independently > to the loggers. The architecture has it that the checkpoints use the > ExecutionEngine interfaces provided to get and write to the loggers > configured. And, you have the application instantiating the logger > directly, which isn't architecturally correct. The application asks > the ExecutionEngine to add a logger, via add_logger(). The application > must pass the appropriate arguments to this call for the logger > instantiation to work. Yes. That's incorrect. I'll correct it. > > The ExecutionEngine also manages logging of the installation sequence. > We need to capture this functionality in the design. I will do this. > > Also, if you could, expand on the use cases, either via UML modeling > or task lists showing the consumers of logging and how they would > interact with the logging object. I think that is a great idea. I'll do that. > > thanks, > sarah > **** > > > On 02/ 8/10 07:13 PM, Virginia Wray wrote: >> Hi All - >> >> I've posted a draft design document for review. Please take a look at: >> https://securewiki.sun.com/download/attachments/78512557/Logging.odt. >> >> Please send comments and questions to caiman-discuss by 2/19. >> >> thx, >>
