On Tue, Oct 6, 2009 at 11:22 PM, James McKinney <ja...@evolvingweb.ca>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 > http://github.com/evolvingweb/AJAX-Solr > > 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 drupal.org, 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 > drupal.org, 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 > drupal.org (only GPL), or apache.org (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 drupal.org > 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.
