Stefan Groschupf wrote:
Hi,
to move forward in the direction of having a nutch gui, I would love
to start removing the static access of NutchConf.
Based on experience first I would love to get a kind of general
agreement and a 'go' before wasting to much time for an unaccented
solution.
I agree with the general direction. Some comments below:
I suggest:
+ removing NutchConf.get().
I'm not sure about this... Somewhere you need to instantiate the default
config, and this looks like a good place.
+ in case a lower level object use only one, two but not more than 3
parameters from the nutch configuration, we add this parameter to the
constructor of this object.
(e.g. MapFile.Reader needs only the parameter INDEX_SKIP)
I don't fully agree with this. In most such cases, you already have a
NutchConf instance in the method or class context, so it makes sense to
use it in the constructor. You could add these construtors with all
parameters iterated, but I'd expect that the constructors using
NutchConf would be used most frequently.
+ for higher level objects like fetcher tool- that need more than 3
parameters for the lower level object - we add a instance of
NutchConf to the Constructor
Ok.
+ for all dynamic used object that implements a specific interface
(interface > no control over the object constructor) we use the
Configurable interface to set the NutchConf in a inversion of control
like style.
(e.g. Plugin Extension Implementations like Parser or Protocols)
Ok.
+ PluginRegestry will not longer a singleton but will get an
constructor with a NutchConf instance.
Definitely yes.
+ Getting a Extension, require also a NutchConf that is injected in
case the Extension Object (e.g. a Parser) implements a Configurable
interface.
Yes. If you remember our discussion, I'd like also to follow a pattern
where such instances are cached inside this NutchConf instance, if
appropriate (i.e. if they are reusable and multi-threaded).
Any comments, improvement suggestions, more use-cases?
I would love to do this job, can I get a go from the other developers?
+1 from me.
--
Best regards,
Andrzej Bialecki <><
___. ___ ___ ___ _ _ __________________________________
[__ || __|__/|__||\/| Information Retrieval, Semantic Web
___|||__|| \| || | Embedded Unix, System Integration
http://www.sigram.com Contact: info at sigram dot com
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Nutch-developers mailing list
Nutch-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nutch-developers
