Hi Shawn, Thanks for the thoughtful response on middleware and the solr philosophy. You are correct and I intend to handle this outside of Solr. This inquiry was me doing some forethought on a distant project. When I see an XSLTResponseWriter the jump-to-conclusions part of my brain jumps to PDF. The separation you are describing is very logical.
At this point I intend to make use of an XSLTresponse to produce formatting objects that I will process at a later point in the application. Or maybe I won't. Solr isn't my upstream source. The data is relational, but my indexes are in solr. I could always process the upstream relational data to produce my PDF reports. Matt On Wed, Oct 19, 2016 at 10:53 AM, Shawn Heisey <apa...@elyograg.org> wrote: > On 10/17/2016 8:01 AM, Matthew Roth wrote: > > Is there a documented or preferred path to have a PDF response writer? > > I am using solr 5.3.x for an internal project. I have an XSL-FO > > transformation that I am able to return via the XSLT response writer. > > Is there a documented way to produce a PDF via solr? Alternatively, I > > was thinking of passing the response through an eXist-db instance [0] > > we have running. However, a pdf response writer would be ideal. > > Solr responses are designed to be processed by a program making a search > query, not read by an end user. Solr is middleware. There are multiple > formats (json, xml, javabin) because we do not know what kind of program > will consume the response. > > https://en.wikipedia.org/wiki/Middleware > > PDF is an end-user format for display and print, not a middleware > response format. Creating content like that is best handled by other > pieces of software, not Solr. > > For best results that fit your needs perfectly, that software is likely > to be something you write yourself. The Solr project has absolutely no > idea how you will define your schema, or how you would like the data in > a Solr response transformed, integrated, and formatted in a PDF. > > Designing the feature you want would be something best handled as an > software project separate from Solr. The software would take a Solr > response and turn it into a PDF. It doesn't fit into Solr's core usage, > so making it a part of Solr is not a good fit and unlikely to happen. > > No matter where the development for a general feature like that happens, > it would likely take weeks or months of work just to reach alpha > quality. After that, it would take weeks or months of additional work > to reach release quality ... and even then it probably wouldn't produce > the exact results you want without extensive and complicated > configuration. Handling complicated configuration is itself very > complicated, which is one reason why development would take so long. > > Thanks, > Shawn > >
