Mike Cannon-Brookes wrote:
0.7 vs 0.8 - apologies if I'm using an old version. I'm using the latest binary release. I'll switch to latest SVN HEAD and see how that works in my application.
The mapred branch will soon be moved to trunk, so you might be better off starting there, since a lot has changed in that branch.
Is there any concrete timeline on 0.8?
Not yet. Once the mapred branch is folded in then there's a bunch of stuff that's obsoleted that needs to be removed. I'd like to get dynamic configuration in, if possible. A JMX-based Nutch would be nice.
At some point, probably just after 0.8, I'd like to move the MapReduce and NDFS code into a separate Lucene sub-project, a distributed computing platform. Perhaps this would be less destabilizing if this were done before 0.8, but, since we're still pre-1.0, I don't yet worry too much about back-compatibility, and I don't want to hold up 0.8 for this.
I'm very glad to see the statics generally being reduced. I also personally (!!) would remove the Nutch configuration system completely in favour of Spring - I believe you'd get a lot more power for very little investment of time - but I realise that's a much more drastic step for a code-newbie to suggest :)
Off the cuff, it sounds like overkill to me. But I might be convinced. Can you draft a short description of what this might look like? E.g., what would we replace calls to NutchConf.getInt() with? How would someone create and modify a configuration from code? This would give me some points to start looking at in the Spring javadocs.
The directory listing in a J2EE application is a problem. Why do you need to get a directory listing? The way we load plugins in J2EE is to say "find me all resources named /plugin.xml", then load each of those XML files, then from there load the relevant classes etc as indicated.
That sounds like directory enumeration. What is the scope of the find? Can you send a few lines of code that show how this is done?
Doug
