If the PDF report is truly a report, I agree with this. We have a use-case with IBM InfoSphere Watson Explorer where our users want a PDF report on the results for their query to be generated on the fly. They can then save the query and have the report emailed to them :) Not only is Solr middleware - Search engines in general should be Middleware, because these sorts of business requirements keep coming up. We've invested a lot in IBM InfoSphere Watson Explorer because it can create a GUI for us, but that often ends-up biting you in the end.
This creates search UI's that are maintained by the "search team" while the corresponding application is maintained by the "developer team", and so look and feel can often be replicated while using different HTML, JavaScript, and CSS. So, updates can be hard, and achieving the same mobile responsive behavior can be nearly impossible. Search engines *should* be middleware. I value having a back-office for crawling the web that allows a crawl to be defined entirely through a GUI, but question whether it really is much better than a FOSS architecture. -----Original Message----- From: Alexandre Rafalovitch [mailto:arafa...@gmail.com] Sent: Friday, October 21, 2016 10:35 AM To: solr-user <solr-user@lucene.apache.org> Subject: Re: PDF writer On 21 October 2016 at 09:58, Matthew Roth <matthew.g.r...@yale.edu> wrote: > . I could always process the upstream relational data to produce my > PDF reports. I think this is the best option. This allows you to mangle/de-normalize your data stored in Solr to be the best fit for search. Regards, Alex. ---- Solr Example reading group is starting November 2016, join us at http://j.mp/SolrERG Newsletter and resources for Solr beginners and intermediates: http://www.solr-start.com/
