Strainer is a HipChat service that identifies mentions, emoticons and
URLs in chat messages.


Installation
============
Strainer API requires the following python packages:
    * eventlet
    * flask
    * lxml
    * beautifulsoup4
    * requests
    * nose
    * requests-mock

To install Strainer in a virtualenv:
    * Create virtual environment
        ``virtualenv strainer-venv``
    * Activate virtual environment
        ``source strainer-venv/bin/activate``
    * Install dependencies
        ``pip install eventlet Flask lxml beautifulsoup4 requests nose requests-mock``


Running Tests
=============
To run tests, execute the ``run_tests.sh`` script in the top-level directory:
    ``./run_tests.sh``


Running Server
==============
To run the server, execute ``server.py`` script in ``strainer`` package.
    ``./strainer/server.py``


Notes
=====

# Improve tests
    * There can be more tests around timing the timeouts while fetching titles.
    * There can be a lot more tests around URL straining testing for various
      kinds of valid and invalid URLs
    * Similarly, testing for title fetching can be improved for a diverse set
      of valid and invalid URLs
    * There can be more tests around unicode characters
    * Functional test coverage may be improved as well. In the interest of
      time, since there is decent unit test coverage for straining and
      fetching, some functional tests that could potentially be testing the
      same thing are skipped here.
    * Documentation in tests can be improved. However, the test names should be
      self-explanatory

# This currently developed and tested on Python 2. May need more effort to make
  it Python 3 compatible.

# If there's no limit on how long a chat message can be, it could be possible
  the API may time out. Is there scope for parallelizing message straining?

# Currently, there are three different regular expressions. One regular
  expression each for straining emoticons, mentions and URLs specifically. Is
  there a way to devise one regular expression that does it all? If so, is
  that going to efficient than the current three?

# Logging could be improved further. Generating and logging request ids could
  prove very useful while troubleshooting

# The use of 'POST' vs 'GET' maybe debated. With GET, the input chat message
  may have to be sent as a body assuming the message can be of any length.
  Sending body with 'GET' is much debated and usually discouraged as there no
  standards defined around processing request body with 'GET'. Hence, the use
  of 'POST' here. Usage of 'POST' could be debated too from a strict RESTful
  sense as the Strainer API doesn't create any resources. 'POST' just happens
  to a better option for this scenario.

# There is probably scope for caching the titles if some URLs appear more
  often than others in chat messages. If the URLs are fairly random, then
  adding cache may not be a big gain. This needs to be studied further.