Thread: RE: [Htmlparser-developer] HTMLParserFeedback
Brought to you by:
derrickoswald
Menu
▾
▴
htmlparser-developer
|
From: Claude D. <CD...@ar...> - 2002-08-05 04:04:08
|
UGxlYXNlIGRvbid0IGludHJvZHVjZSBhbnkgZGVwZW5kZW5jaWVzIG9uIG90aGVyIGxpYnJhcmll cy4gVGhlIEZlZWRiYWNrIG1vZGVsIGlzIGludGVuZGVkIHRvIGFsbG93IHVzZXJzIHRvIHJlZGly ZWN0IG91dHB1dCB0byB3aGVyZXZlciB0aGV5IHNlZSBmaXQgZm9yIHRoZWlyIGFwcGxpY2F0aW9u LiBUaGUgZGVmYXVsdCBzZW5kcyBvdXRwdXQgdG8gdGhlIGNvbnNvbGUgYnV0IGl0J3MgZWFzeSBm b3IgaW1wbGVtZW50ZXJzIHRvIG1ha2UgbW9yZSBsb2NhbCBkZWNpc2lvbnMgYmFzZWQgb24gdGhl aXIgY29udGV4dCwgYnkgcmVwbGFjaW5nIHRoZSBkZWZhdWx0IGltcGxlbWVudGF0aW9uLCBzbyBs b25nIGFzIHRoZSBpbnRlcmZhY2UgaXMgdmFsaWQuIFRoZSB3aG9sZSBpZGVhIG9mIGEgbGlicmFy eS9mcmFtZXdvcmsgaXMgdGhhdCB0aGUgaW5wdXQvb3V0cHV0IGlzIGNvbnRyb2xsYWJsZSBieSB0 aGUgZGV2ZWxvcGVyIHVzaW5nIGl0LiBZb3UgZG9uJ3Qgd2FudCBhbnkgY291cGxpbmcgdG8gb3Ro ZXIgbGlicmFyaWVzLiBMZXQgZGV2ZWxvcGVycyBkZWNpZGUgd2hhdCdzIHN1aXRhYmxlIGZvciB0 aGVpciBhcHBsaWNhdGlvbi4gSXQncyBzaW1pbGFyIHRvIHRoZSBFcnJvckhhbmRsZXIgaW4gU0FY LCB0aG91Z2ggaW4gdGhlaXIgY2FzZSwgdGhlIG91dHB1dCBnb2VzIG5vd2hlcmUgYnkgZGVmYXVs dC4gSXQncyB1cCB0byB1c2VycyB0byBkZWNpZGUgd2hhdCB0byBkby4NCiANCllvdSdsbCBub3Rp Y2UgdGhhdCB0aGUgRmVlZGJhY2sgY2xhc3NlcyBpbnRyb2R1Y2UgYSBtb2RlbCB0aGF0IGxpYnJh cnkgZGV2ZWxvcGVycyBjYW4gdXNlIHRvIGRpcmVjdCBvdXRwdXQgdG8gYSBwbGFjZSB0aGF0IHdv bid0IGludGVyZmVyZSB3aXRoIHRoZSBsaWJyYXJ5IHVzZXIvZGV2ZWxvcGVyJ3Mgbm90aW9uIG9m IHdoZXJlIHRoaW5ncyBjb3VsZCBnby4gSSd2ZSBiZWVuIG1lYW5pbmcgdG8gd3JpdGUgc29tZXRo aW5nIG1vcmUgc3BlY2lmaWMgYWJvdXQgdGhpcyBkZXNpZ24gcGF0dGVybiBidXQgdGhpbmdzIGp1 c3Qga2VlcCBnZXR0aW5nIGluIHRoZSB3YXkuIEluIGFueSBjYXNlLCB1c2UgdGhlIEZlZWRiYWNr IG1lY2hhbmlzbSBhcyBhIHdheSBvZiBhbGxvd2luZyB1c2VycyB0byBkZWNpZGUgd2hlcmUgdGhl IG91dHB1dCBzaG91bGQgZ28gb3Igd2hldGhlciBpdCBzaG91bGQgYmUgaWdub3JlZC4gQ29uc2lk ZXIgaXQgYSByZXBsYWNlbWVudCBmb3IgU3lzdGVtLm91dCBhbmQgU3lzdGVtLmVyci4gVXNlcnMg Y2FuIGxhdGVyIGRlY2lkZSB3aGV0aGVyIHRoZSBvdXRwdXQgKHdoaWNoIGZhbGxzIGludG8gc2lt cGxlIGNhdGVnb3JpZXMpIHNob3VsZCBiZSBsb2dnZWQsIHNlbmQgdG8gdGhlIGNvbnNvbGUsIHdy aXR0ZW4gdG8gYSBHVUksIHJlcm91dGVkIHRvIHNvY2tldHMsIGZpbHRlcmVkIGJ5IHBpcGVsaW5l cyBvciBzaW1wbHkgaWdub3JlZC4gVGhlIGJlYXV0eSBvZiB0aGlzIGRlc2lnbiBpcyBhbGwgaW4g dGhlIHVuY291cGxpbmcsIHVzaGMgdGhhdCB0aGUgbGlicmFyeSB1c2VyIGRlY2lkZXMgd2hhdCdz IHJlbGV2YW50IGluIHRoZWlyIGFwcGxpY2F0aW9uLg0KIA0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0gDQpGcm9tOiBTb21payBSYWhhIFttYWlsdG86c29taWtAeWFob28uY29tXSANClNlbnQ6 IFN1biA4LzQvMjAwMiAxMjozNCBBTSANClRvOiBodG1scGFyc2VyLWRldmVsb3BlckBsaXN0cy5z b3VyY2Vmb3JnZS5uZXQgDQpDYzogDQpTdWJqZWN0OiBbSHRtbHBhcnNlci1kZXZlbG9wZXJdIEhU TUxQYXJzZXJGZWVkYmFjaw0KDQoNCg0KCUhpIERldmVsb3BlcnMsDQoJICAgIFRoaXMgaXMgdG8g aW5pdGlhdGUgYSBkaXNjdXNzaW9uIG9uIHRoZSBuZXh0IHN0ZXAsIG9uIGludGVncmF0aW9uIGZl ZWRiYWNrIGludG8gdGhlIHBhcnNlci4gQ2xhdWRlIGhhZCBzdWJtaXR0ZWQgSFRNTFBhcnNlckZl ZWRiYWNrIGludGVyZmFjZSAoaW4gdGhlIHV0aWwgcGFja2FnZSkgLSB3aGljaCBhbGxvdyB1cyB0 byBsb2cgdGhlIGFjdGl2aXR5IG9mIHRoZSBwYXJzZXIsIGluZm9ybSB3aGVuIGVycm9ycyBvY2N1 ciwgYW5kIHNob3cgd2FybmluZ3MuIA0KCSANCgkgICAgSSBhbSBmYW1pbGlhciB3aXRoIGxvZzRq LCBhbmQgdGhpcyBzb3VuZHMgcHJldHR5IHNpbWlsYXIgLSBpbiB0ZXJtcyBvZiBmdW5jdGlvbmFs aXR5LCBpdCBzb3VuZHMgZ29vZC4gQnV0IGluIHRlcm1zIG9mIHBlcmZvcm1hbmNlLCBteSBxdWVz dGlvbiBpcyA6DQoJWzFdIFdpbGwgdGhpcyByZXN1bHQgaW4gYW4gdW5hY2NlcHRhYmxlIHBlcmZv cm1hbmNlIGhpdCA/DQoJWzJdIFNob3VsZCB3ZSBwcm92aWRlIGFsdGVybmF0ZSBjb25zdHJ1Y3Rv cnMgb3IgbW9kaWZ5IGV4aXN0aW5nIEFQSSA/IElmIHdlIHByb3ZpZGUgYWx0ZXJuYXRlcywgdGhl biB3aGF0IGRlZmF1bHQgYmVoYXZpb3VyIHdvdWxkIGJlIGJlc3QgPyBBcmUgd2UgdGFsa2luZyBh Ym91dCBkZWZhdWx0IGNhbGxiYWNrIG9iamVjdHMgLSBpZiB5ZXMsIHRoZSBzdHJpbmdzIGNyZWF0 ZWQgZm9yIGVhY2ggY2FsbCB3b3VsZCBzbG93IGRvd24gdGhlIHBhcnNlci4NCgkgDQoJICAgIEl0 IHdvdWxkIGJlIGdyZWF0IHRvIGhhdmUgc29tZSB0aG91Z2h0cyBvbiB0aGlzLg0KCSANCglSZWdh cmRzLA0KCVNvbWlrDQoJIA0KCSANCg0K |
|
From: Claude D. <CD...@ar...> - 2002-08-06 16:05:56
|
Great! Check out the Log class in the JavaDocs for the Apache Commons project:=20 <http://jakarta.apache.org/commons/logging.html> http://jakarta.apache.org/commons/logging.html It's intented to provide an abstraction that maps onto various logging libraries (Log4J, JDK14 logging, etc). The API for the Log class looks similar to the one I proposed. The main distinctions are that they've used Object types for the message (I'd presume they count on the toString method for logging) and they have more methods. I think there's room for adding methods in the Feedback API, but I'd be inclided to do it on an as-needed basis. -----Original Message----- From: Somik Raha [mailto:so...@ya...]=20 Sent: Monday, August 05, 2002 7:04 PM To: htm...@li... Subject: Re: [Htmlparser-developer] HTMLParserFeedback 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. =20 Regards, Somik ----- Original Message -----=20 From: Claude <mailto:CD...@ar...> 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 |
|
From: Somik R. <so...@ya...> - 2002-08-06 02:10:44
|
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
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X