Steven,
I'm heads-down building a Ruby library (solrb) to access Solr. It
currently has some basic capabilities, but will evolve a lot in the
near future:
<http://wiki.apache.org/solr/solrb>
I've not worked with JRuby yet myself, but I certainly think what
you're up to is good stuff.
Erik
On Jan 19, 2007, at 6:17 AM, Otis Gospodnetic wrote:
I think this would most definitely be a good addition, and would
buy you at least a pint of beer from Erik.
You probably want something less generic than contrib/jruby,
though. ruke? lurb? yuyhqjndusdsdund? ;)
Keeping the "connection" to the index (IndexReader opened) would be
nice, esp. for looking at large indices.
It might also be interesting to think about this as a Web/HTTP API
for access to data about the index, so it can be accessed
programmatically, not just by people & browser. I'm thinking
something like Solr's Admin pages. They return XML and transform
that to XSL-browser side when accessed by the browser, or just raw
XML when accessed without a browser. Of course, one could return
other formats, too, not just XML: JSON, Ruby itself...
Otis
----- Original Message ----
From: Steven Parkes <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Wednesday, January 17, 2007 9:27:37 PM
Subject: jruby anyone?
I've been playing with using jruby to script, drive, and otherwise
front-end Lucene activities. I wondered originally about using it to
develop a domain specific language for exploring Lucene performance.
Now, with Doron's stuff, that may not really be necessary (and,
besides,
throwing jruby into the mix might skew performance, though if it's
just
the outer scripting being done in ruby, it might be okay.)
Anyway, coming up to speed on jruby, I also looked at rails. I've
started on a luke-like jruby-on-rails application and, well, at
least it
doesn't suck. Very quick to prototype things (though in the spirit of
full-disclosure, that's coming from someone who's a big proponent of
dynamically-typed languages and willfully incompetent when it comes to
GUI toolkits).
It includes
1) jruby wrappers for the Lucene stuff (at least what I've needed so
far)
2) rails models for some of the Lucene stuff
3) my luke-like app (luki? lucky? juki? ???)
It's still fairly early. The web app is pretty crude, but
functional for
the basics. (One of the things I'm wonder is whether this platform
(once
one gets the platform running) is easier for people to add
functionality
to.)
I've been trying to make the jruby bindings rubiesque, at least what I
think is rubiesque. This means to me, more like the putative grand
unified index interface talked about here on dev.
I'm still thinking through the web/rails model. Rails normally uses an
rdbms backend and maintains a connection to the db. Right now, I'm not
keeping a connection to the index. Rails also reifies tables as
classes,
so I've been playing with what that means for Lucene.
This is just diagnostic stuff, performance isn't really and issue.
What's done in ruby is mostly UI stuff and once you're in java, it
runs
at speed. I did come across one place where this wasn't the case.
To do
term ordering by doc freq, you need to get all the terms and sort
them.
This is fairly fast in java, for say 80K terms. Making 80K very
lightweight calls from ruby to java is not a good idea at this
point. So
I factored out the necessary sorting code into a java util method and
call it from ruby. Doesn't change the api. Integrates nicely. The
jruby
guys have done a good job.
My goal is to get this to the point where I can generate a war file
that
can be loaded into any web container. So far, I've just been
running it
under ruby's webrick container. And it does require bleeding edge
(trunk) jruby and rails.
Like I said, it's early, but if others are interested in looking at
it?
Maybe contrib/jruby?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
