lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Israel Ekpo <>
Subject Re: 8 for 1.4
Date Wed, 07 Oct 2009 03:29:19 GMT
On Tue, Oct 6, 2009 at 11:22 PM, James McKinney <>wrote:

> Hi all, I only just now discovered this thread on the future of
> SolrJS. I'm one of the Drupal developers that worked on the SolrJS
> fork that we call AJAX Solr. The code is up at
> Before I address some of the concerns that came up earlier in the
> thread, I'd just like to thank Matthias and any contributors for their
> work on SolrJS, which provided an excellent API and framework in which
> to add more features and improve existing ones.
> Now: why did we fork SolrJS instead of patching? A fork was preferable
> for two reasons. (1) we would have had to make a lot of patches and
> (2) we needed the code to be licensed under GPL in order to publish it
> on, which is the one and only place Drupal developers go to
> share code.
> As to (1), it is entirely possible some of our patches would not have
> been accepted, even though they are useful to us, so it would have
> probably been inevitable that we start a fork. As we were hacking
> SolrJS for one of our clients, not for its own right, we also got
> quite far from the original code, so writing atomic patches would have
> taken months (we don't work full-time on this).
> As to (2), AJAX Solr is currently tri-licensed as GPL v2, ASL v2, and
> MIT. We don't really care about the license. It's GPL v2 for
>, ASL v2 for consistency with SolrJS, and MIT for
> consistency with Ruby on Rails, for which we hope to one day release a
> plugin, as we have done for Drupal (the Drupal module will be released
> this weekend). If it were up to me, I'd just make the code public
> domain. I'm not religious about licences.
> We set up the GitHub account so that people could contribute code
> there, under all three licenses, instead of contributing code at
> (only GPL), or (only ASL?). I will not accept a
> patch unless I can release it under those three licenses. I think this
> will avoid any licensing issues and address the licensing concerns I
> read earlier in the thread.
> RE: Shalin Shekhar Mangar: "Are they exposing their Solr servers to
> the public so that it can be accessed directly through Javascript?" In
> our Drupal module, we provide the option to either expose the Solr
> server to the public (not recommended), or to proxy requests through
> Drupal (recommended) or even a custom proxy. Our Drupal proxy filters
> the request prepared by the JavaScript, returning only those fields
> that the administrator set as publicly accessible, and limiting the
> number of rows returned to the administrator-set maximum.
> Also, as to the name, a few things: one of our developers, when we
> were still thinking of patching SolrJS, created a module on
> called "solrjs". As we won't be using SolrJS, we will rename that
> appropriately. If anyone objects to the name "AJAX Solr" please let me
> know. I don't think it's a problem to have "Solr" in the name; it
> would be terribly confusing if it didn't.
> Thanks,
> James
> P.S.: Since I just joined the list, I didn't know how to reply to the
> thread with all the thread history attached. Sorry if this causes
> problems with the mailing list.

Hi James,

You almost gave me heart attack by using that subject line "Re: 8 for 1.4".
I remember checking a few minutes ago and it was just 4 issues remaining.

I can't wait for 1.4 to be released officially.

Maybe "Re: 4  for 1.4" would be more appropriate. :)

"Good Enough" is not good enough.
To give anything less than your best is to sacrifice the gift.
Quality First. Measure Twice. Cut Once.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message