Re: [Htmlparser-developer] HTMLParserFeedback

[Somik R. <so...@ya...>]

Hi Claude,
    No no, I wasnt planning to use log4j for the parser :)
    Just mentioning that the model is so similar. J2SDK 1.4.x of course =
has the same logging stuff in their APIs.
    I agree with your reasoning - we'll start putting in the feedback =
classes down the line. Let me see if I can find some time in the weekend =
to analyze this. If anyone else wants to try this integration - pls feel =
free.

Regards,
Somik
  ----- Original Message -----=20
  From: Claude Duguay=20
  To: htm...@li...=20
  Sent: Monday, August 05, 2002 1:04 PM
  Subject: RE: [Htmlparser-developer] HTMLParserFeedback


  Please don't introduce any dependencies on other libraries. The =
Feedback model is intended to allow users to redirect output to wherever =
they see fit for their application. The default sends output to the =
console but it's easy for implementers to make more local decisions =
based on their context, by replacing the default implementation, so long =
as the interface is valid. The whole idea of a library/framework is that =
the input/output is controllable by the developer using it. You don't =
want any coupling to other libraries. Let developers decide what's =
suitable for their application. It's similar to the ErrorHandler in SAX, =
though in their case, the output goes nowhere by default. It's up to =
users to decide what to do.
  =20
  You'll notice that the Feedback classes introduce a model that library =
developers can use to direct output to a place that won't interfere with =
the library user/developer's notion of where things could go. I've been =
meaning to write something more specific about this design pattern but =
things just keep getting in the way. In any case, use the Feedback =
mechanism as a way of allowing users to decide where the output should =
go or whether it should be ignored. Consider it a replacement for =
System.out and System.err. Users can later decide whether the output =
(which falls into simple categories) should be logged, send to the =
console, written to a GUI, rerouted to sockets, filtered by pipelines or =
simply ignored. The beauty of this design is all in the uncoupling, ushc =
that the library user decides what's relevant in their application.
  =20
  -----Original Message-----=20
  From: Somik Raha [mailto:so...@ya...]=20
  Sent: Sun 8/4/2002 12:34 AM=20
  To: htm...@li...=20
  Cc:=20
  Subject: [Htmlparser-developer] HTMLParserFeedback



  Hi Developers,
      This is to initiate a discussion on the next step, on integration =
feedback into the parser. Claude had submitted HTMLParserFeedback =
interface (in the util package) - which allow us to log the activity of =
the parser, inform when errors occur, and show warnings.=20

      I am familiar with log4j, and this sounds pretty similar - in =
terms of functionality, it sounds good. But in terms of performance, my =
question is :
  [1] Will this result in an unacceptable performance hit ?
  [2] Should we provide alternate constructors or modify existing API ? =
If we provide alternates, then what default behaviour would be best ? =
Are we talking about default callback objects - if yes, the strings =
created for each call would slow down the parser.

      It would be great to have some thoughts on this.

  Regards,
  Somik