lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James McKinney <>
Subject Re: 8 for 1.4
Date Wed, 07 Oct 2009 03:22:09 GMT
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.



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.

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