Renaming the Perl client


In September 2013 I released the official Perl client: Elasticsearch.pm and deprecated my old client which was called ElasticSearch.pm (note the capital S).

At the time I was under the impression that PAUSE was case-sensitive and thought that the similarity of the names might cause a small human problem but wouldn’t be a technical problem. Shortly after release, @karenetheridge pointed out to me (#5) that users of case insensitive filesystems (Windows and OSX) would be unable to install both versions of the module at the same time, making migration problematic.

I then released Elasticsearch::Compat, which provides the old API but uses the new Elasticsearch.pm client internally, hoping that this would ease migration. However, there are a number of modules that depend on the old client and so conflicts continue to occur. This issue was raised again last week in #18.

All of the official clients are named Elasticsearch so I was loathe to change the name, but after talking the problem through with the cool headed @neilbowers (++), he convinced me of the need to:

  1. Deprecate both ElasticSearch.pm and Elasticsearch.pm and,
  2. To release the official client under a new name with no possibility of clashes.

This will cause some pain (for which I apologise) to users who have already migrated to the new Elasticsearch.pm as they will need to update their code to use the new name, but it is the better long term solution.

What should it be called?

I would like feedback from users of the module as to what the new name should be. Suggestions so far include Search::Elasticsearch and Elasticsearch::V2. Any other suggestions are welcome. Please vote for your preferred name in the comments below this issue: https://github.com/elasticsearch/elasticsearch-perl/issues/20.

Donation to QA Hackathon

CPAN is the jewel of Perl and we owe an enormous debt of gratitude to those who maintain and improve it. Elasticsearch.com are proud to contribute to this important effort by donating $1,000 to the upcoming QA Hackathon in Lyon in March. A big thank you to the volunteers who give their time to improving the Perl ecosystem.

Future plans for elasticsearch-perl

Faster HTTP backends

Thanks to @mjegh and @dagolden, the latest version of HTTP::Tiny now supports persistent connections and is considerably faster. I have already changed the default HTTP backend from LWP to HTTP::Tiny.

The new pure Perl Hijk HTTP client is faster even than the libcurl-based Net::Curl, and I will be adding it as an optional backend. It is a specialized client which doesn’t offer support for proxies or https, which is why HTTP::Tiny is the default, but it will be a great solution for many users.

Async client

The old ElasticSearch.pm had an AnyEvent backend, but the code was complex and difficult to maintain. In the works is a new async client which uses the awesome (@stevan++) Promises module, which can be used with AnyEvent, EV or Mojo. Adding support for other event loops is simple. Promises make async code as readable as sync code. Take a look at Promises – A gentle intro.

The current code for the Promises integration can be seen at https://github.com/elasticsearch/elasticsearch-perl/tree/promises. The code and tests are all written, we’re just missing the documentation.

Elastic::Model

A lot has changed in Elasticsearch since the last release of Elastic::Model. It needs to be updated to use the new Perl client and to expose all of the new features available in Elasticsearch v1. This will be a major change but I hope to provide code to make migration easy.