Hi Julien and Sebastian, Thank you for your replies!
(both replies had a lot of similarities, so I'll answer them both) On 6 April 2016 at 14:16, Sebastian Nagel <wastl.na...@googlemail.com> wrote: > > One site is indexed by Nutch. Now it should be limited to the pages that > > are linked in the seed URL (no further crawling necessary). > Have a look at the plugin "scoring-depth" and add to your nutch-site.xml > (cf. conf/nutch-default.xml): > > > <!-- scoring-depth properties > Add 'scoring-depth' to the list of active plugins > in the parameter 'plugin.includes' in order to use it. > --> > > <property> > <name>scoring.depth.max</name> > <value>2</value> > <description>Max depth value from seed allowed by default. > Can be overridden on a per-seed basis by specifying "_maxdepth_=VALUE" > as a seed metadata. This plugin adds a "_depth_" metadatum to the pages > to track the distance from the seed it was found from. > The depth is used to prioritise URLs in the generation step so that > shallower pages are fetched first. > </description> > </property> > Will try that. > > > Furthermore all > > pages must be revisited daily (and new pages must be indexed daily too). > > See property "db.fetch.interval.default", > also take the time to check other > db.fetch.interval.* > db.fetch.schedule.* > properties. > Is my assumption correct that if <property> <name>db.fetch.schedule.class</name> <value>org.apache.nutch.crawl.DefaultFetchSchedule</value> <description>The implementation of fetch schedule. DefaultFetchSchedule simply adds the original fetchInterval to the last fetch time, regardless of page changes.</description> </property> is used that only db.fet.interval.default is used? All the other properties are then ignored? > > Another wish is to exclude pages with certain content on them. Currently > we > > do this by a delete query after Nutch finishes. We can keep it this way, > > but I wondered if there was a smarter option. > > How is such content identified? > It sounds really stupid, but the maker of that site does not output a 404 header, but puts an HTML formatted message on the page like "Code 303 Description you are not allowed to access this item" Currently my cron job just calls the solr update handler and sends a delete query that searches for content matching "Code 303 Description" (all HTML and whitespace are stripped anyway in the solr index) in the stream body. Writing a plug in to filter this out is indeed cleaner, but the work involved is too much compared to what is gained. The workaround does its job. If there was a plugin that does this already that would be nice. -- Met vriendelijke groet, Jigal van Hemert | Ontwikkelaar Langesteijn 124 3342LG Hendrik-Ido-Ambacht T. +31 (0)78 635 1200 F. +31 (0)848 34 9697 KvK. 23 09 28 65 ji...@alternet.nl www.alternet.nl Disclaimer: Dit bericht (inclusief eventuele bijlagen) kan vertrouwelijke informatie bevatten. Als u niet de beoogde ontvanger bent van dit bericht, neem dan direct per e-mail of telefoon contact op met de verzender en verwijder dit bericht van uw systeem. Het is niet toegestaan de inhoud van dit bericht op welke wijze dan ook te delen met derden of anderszins openbaar te maken zonder schriftelijke toestemming van alterNET Internet BV. U wordt geadviseerd altijd bijlagen te scannen op virussen. AlterNET kan op geen enkele wijze verantwoordelijk worden gesteld voor geleden schade als gevolg van virussen. Alle eventueel genoemde prijzen S.E. & O., excl. 21% BTW, excl. reiskosten. Op al onze prijsopgaven, offertes, overeenkomsten, en diensten zijn, met uitzondering van alle andere voorwaarden, de Algemene Voorwaarden van alterNET Internet B.V. van toepassing. Op al onze domeinregistraties en hostingactiviteiten zijn tevens onze aanvullende hostingvoorwaarden van toepassing. Dit bericht is uitsluitend bedoeld voor de geadresseerde. Aan dit bericht kunnen geen rechten worden ontleend. ! Bedenk voordat je deze email uitprint, of dit werkelijk nodig is !
