Here are my thoughts (and progress) so far on the subject:
I have ported about half of the API at home, and am testing it while
also building some simple unit tests.
Once I am satisfied that the port covers the complete current API, I
will donate this to Apache for review and whatever we then choose what
to do next.
While this is not a 'rewrite' but rather a port, there are some changes
made to the way it works internally:
Improvements/changes:
- Abstract AAA away from endpoints. Don't trust stats.lua (or stats.py)
to handle security, put that in a core mbox library for fetching emails.
- No or very little raw ES queries in the end points (have a library for
this, "fetchEmail", "fetchList" etc which handles the AAA aspect for all
end points)
- Refactor the fuzzy search logic for stats.py, separate to its own
library, so both stats, mbox and atom can use it. Imagine downloading an
mbox file with emails matching a search/range, or subscribing to an
email search as an atom feed.
- Ditch debug/timing outputs entirely, JS can handle much of this.
Proposed structure:
Standard WSGI application, can be run with mod_wsgi in apache, or as
standalone via gunicorn or similar app.
wsgi --\
- handler.py (WSGI handler, grab session/DB and run end point)
- pages --\
- stats.py
- atom.py
- preferences.py
- etc
- plugins --\
- defuzzer.py (search logic for stats/atom/mbox)
- mbox.py (fetch one/more email(s), check AAA)
- aaa.py (AAA lib)
- aaa_*.py (additional AAA libs, not tracked)
- database.py (abstract ES object)
- session.py (session object)
- tests --\
- defuzzer.py (tests for defuzzer)
- aaa.py (tests for AAA)
- etc
This would be backwards compatible in that the new endpoints would be
/api/stats etc, but /api/stats.lua would also be accepted.
I could also be persuaded to just dump everything I have into the PM
repo under a branch (it's in VCS already, so history would be preserved)
if someone thinks that's a good idea. People could then test this very
easily with gunicorn or similar.
With regards,
Daniel.
