[
https://issues.apache.org/jira/browse/SOLR-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770925#action_12770925
]
Chris A. Mattmann commented on SOLR-1516:
-----------------------------------------
Shalin, I guess what I'm trying to raise is a larger issue. You mention "we"
had an agreement on where to draw the line for "new issues". Well, what's a
"new issue"? And, who's "we"? What's SOLR's process for new features versus bug
fixes, etc.? I don't see it documented anywhere but I think it seems pretty
clear to you what the process is. Admittedly I've only been actively monitoring
the SOLR list for a few weeks now, so perhaps it was discussed on the mailing
lists before at some point. Is this something that can be put up (or is
already) on the Wiki? Or perhaps you can point me to it?
I know in 2005 for Nutch, we had a release vote called on 0.7 which was a large
release and a big time production like Solr 1.4. I also know that, at the last
minute, someone mentioned that there was an RSSParser out there in patch land,
that only added functionality, didn't take anything away, didn't touch core
modules, and was sufficiently commit worthy (javadocs, unit tests [if
applicable], etc.) Nutch was very much in the same type of release cycle back
in that day that Solr was: huge release, many months in between releases, etc.,
so it was just as sacrilegious back then for these folks to ask whether the
RSSParser could be included in Nutch at the last minute before a release vote,
and after a discussed "freeze" on features. However, the Nutch committers took
a step back, discussed the pros/cons (briefly, nothing major) over a few emails
and decided why not? At the time, Nutch was producing a release pretty
infrequently, so getting something into a release meant it was going to be out
there for more people to use, touch, test, and leverage, which was a good thing
since the next release wouldn't be coming for a while. And, I think we can all
agree, releases are different than trunk, or patched versions of software. In
many organizations, folks just aren't comfortable with saying, "depend on the
latest trunk" or "depend on release X + patch Y". Releases sound more official
to management.
I'm fine with this patch not getting into 1.4 and I'll drop it since no one
else really seems to be commenting on this and I was just trying to see if
there was interest, which I hope is something that's allowed and encouraged
over here in SOLR land. Everyone wants to feel like there is opportunity to be
included and to ask questions and everyone wants a chance to have their patch
included in a big release that will be widely disseminated.Beyond that,
thinking through this issue made me ask myself yesterday (and with my earlier
comment), well, "how are the SOLR users writing these response writers?", or,
"are they even doing it that much?" So, I was trying to use this issue as a
placeholder to obtain feedback on that.
Chris
> DocumentList and Document QueryResponseWriter
> ---------------------------------------------
>
> Key: SOLR-1516
> URL: https://issues.apache.org/jira/browse/SOLR-1516
> Project: Solr
> Issue Type: New Feature
> Components: search
> Affects Versions: 1.3
> Environment: My MacBook Pro laptop.
> Reporter: Chris A. Mattmann
> Priority: Minor
> Fix For: 1.5
>
> Attachments: SOLR-1516.Mattmann.101809.patch.txt
>
>
> I tried to implement a custom QueryResponseWriter the other day and was
> amazed at the level of unmarshalling and weeding through objects that was
> necessary just to format the output o.a.l.Document list. As a user, I wanted
> to be able to implement either 2 functions:
> * process a document at a time, and format it (for speed/efficiency)
> * process all the documents at once, and format them (in case an aggregate
> calculation is necessary for outputting)
> So, I've decided to contribute 2 simple classes that I think are sufficiently
> generic and reusable. The first is o.a.s.request.DocumentResponseWriter -- it
> handles the first bullet above. The second is
> o.a.s.request.DocumentListResponseWriter. Both are abstract base classes and
> require the user to implement either an #emitDoc function (in the case of
> bullet 1), or an #emitDocList function (in the case of bullet 2). Both
> classes provide an #emitHeader and #emitFooter function set that handles
> formatting and output before the Document list is processed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
