DOCS
----

- add a simple demo, usage instructions and help (to the plugin's _site).

BUGS/ TESTS
-----------

- fields.{x} should work even if the search spec doesn't expose it (so that we can cluster on larger fields without propagating
  the content over the network).

- add a test verifying these schemes work: 
  <li><code>/{index}/_search_with_clusters</code></li>
  <li><code>/{index}/{type}/_search_with_clusters</code></li>

- support for GET queries

FEATURES
--------

- configurable algorithms.
- how to pass algorithm settings?
- resource lookup (lexical resources, licensing for Lingo3G)


PERFORMANCE/ ROBUSTNESS
-----------------------

- check for error resilience and propagation (invalid query request, for example).

- add a test case with yaml body (or other xcontent)

- performance implications and performance testing (threading inside actions/ dispatched actions)? 


REFACTORINGS/ ITCHES
--------------------

- add/move source() parsing from REST to the request builder/object.

- Should we limit or augment the search window somehow (so that the clustering takes place on, say, 100 top results,
  but the returned list is only the top-k)? 
  This is problematic from the technical POV (parsed SearchRequest doesn't expose the internal search request directly;
  uri parameters get injected as extraSource); in most cases the user will need all document references anyway to link
  them up from clusters. Leaving for now. The search query determines the number of documents (and the type of aggregation,
  etc.) to use.

DOCS
----

- add highlighter field mapping example (and rationale)
- add GET request example


BUGS/ TESTS
-----------

- fields.{x} should work even if the search spec doesn't expose it (so that we can cluster on larger fields without propagating
  the content over the network).

- add a test verifying these schemes work: 
  <li><code>/{index}/_search_with_clusters</code></li>
  <li><code>/{index}/{type}/_search_with_clusters</code></li>

- support for GET queries

FEATURES
--------

- configurable algorithms.
- how to pass algorithm settings?
- resource lookup (lexical resources, licensing for Lingo3G)


PERFORMANCE/ ROBUSTNESS
-----------------------

- check for error resilience and propagation (invalid query request, for example).

- add a test case with yaml body (or other xcontent)

- performance implications and performance testing (threading inside actions/ dispatched actions)? 


REFACTORINGS/ ITCHES
--------------------

- add/move source() parsing from REST to the request builder/object.

- Should we limit or augment the search window somehow (so that the clustering takes place on, say, 100 top results,
  but the returned list is only the top-k)? 
  This is problematic from the technical POV (parsed SearchRequest doesn't expose the internal search request directly;
  uri parameters get injected as extraSource); in most cases the user will need all document references anyway to link
  them up from clusters. Leaving for now. The search query determines the number of documents (and the type of aggregation,
  etc.) to use.

Add GET example to the docs.
Add GET example to the docs.
