On Feb 13, 2007, at 2:51 AM, Coda Hale wrote:
We're on the *verge* of deploying the first round of user-facing Solr
functionality at my work (using solrb), and it's amazing. Almost a
million records and we can still run stupid-complicated queries ("find
me anything with at least 4 of these 10 tags") in milliseconds. solrb
is *really* working well, especially since it's so light-weight.
Fantastic!
Some changes I'd like to see (and will be willing to help out with):
* gem packaging and distribution on rubyforge (along with a quick
release schedule)
I personally am currently -0 to -1 on releasing solrb at rubyforge.
I know its the "Ruby Way", but we're at Apache and I'd like to do
this the "Apache Way". Making releases available elsewhere is
frowned upon.
I have no objections, for the time being, to us checking in packages
(.gem/.tar/etc) under the pkg directory as "release candidates" and
allowing folks to "gem install -source ... " them. I think the
additional -source switch gives Ed heartburn, though I really want to
make sure we do this the Apache way as much as possible.
I can set up nightly builds and test runs and publish nightly
packages too if we want.
Ideally solrb will stay lock-step with Solr releases so you can
always rely on a particular solrb version to work with a particular
Solr version.
* add XML parsing capability to libxml-ruby code
She's all yours, Coda :)
* better documentation, both on the method level and on the
integration level
My bad. I was just reading the rdoc documentation in the Pickaxe
book. We can all chip in on this, but I'll take a stab in the near
future at improving this myself.
* more modular request/response design
Something I'd love to see also. I think the request and response
code doesn't need to be so separate.
* better security -- make sure Solr gets passed sanitary data
Care to elaborate on this?
* query builder DSL?
Query Builder *UI* is what I'm after.
I'm sure once we roll out more functionality based on solrb I'll have
a lot more ideas.
Thanks Coda!
Erik
