LJ::EventLogRecord and LJ::EventLogSink: remove completely or finish implementation?

[pauamma]

So Dreamwidth has an incomplete implementation of the LJ::EventLogRecord and LJ::EventLogSink system. Specifically, it's missing LJ::EventLogSink and LJ::EventLogSink::*, and thus doesn't do anything now except waste CPU time and RAM (assuming it's even used anywhere - it's disabled in the stock etc/config*.pl and in the Dreamwidth production configuration). (Note: this has no connection with the ESN system.)

If completed (mostly by importing the missing bits from LiveJournal), it would let us:
- selectively log to the database events listed in http://code.livejournal.org/trac/livejournal/browser/trunk/cgi-bin/LJ/EventLogRecord/
- feed some or all of the same events to an indexer (for full text search of journals) in a way similar to http://code.livejournal.org/trac/livejournal/browser/trunk/cgi-bin/LJ/EventLogSink/SearchIndexer.pm

So it has potential uses if completed, but since Dreamwidth has its own indexer/search engine and no one called for completing it, I think we may as well remove it. Does anyone see any reason for completing it instead? Completing it would mean reverting part of bug 164 - the database logging would still stay out, but the feed-to-indexer bits would return, probably in a modified form).

What do y'all think?

lookup-routing: tool to help navigate the routing system

[fu]

exor674 has added another tool to the dev tools repository, called lookup-routing

It does several things.

First, you can easily find out which file handles what page (e.g., /nav, /nav/create, /rename, /admin, /post, etc).

$ lookup-routing /admin
app: /admin is a redirect to /admin/
app: /admin/ is defined in the file cgi-bin/DW/Controller/Admin.pm, and using the handler sub admin_handler

This is useful if you're working on a bug that's been reported on /some/path/here, and you want to know which file to open up first.

(Psst If "lookup-routing /some/path" doesn't work, it is probably a BML file. Try htdocs/some/path.bml)


( --verbose gives you a much more detailed view (plus some debugging tips) )

Second, you can get a list of everything in the routing table, using the --list argument:
$ lookup-routing --list

You can filter the list down to either those that use regex matching, or those that use string-matching:
$ lookup-routing --list --regex
$ lookup-routing --list --string


You can also filter down to just those pages in user-space, app-space, or ssl using --role=user, --role=app, --role=ssl, respectively. Default is --role=all.

There are --user, --app, --ssl shortcuts which do the same as their --role=... equivalents.

$ lookup-routing --list --user # lists paths handled by the routing system that follow the form http://exampleusername.dreamwidth.org/some/path/here
$ lookup-routing --list --app # lists paths handled by the routing system that follow the form http://www.dreamwidth.org/some/path/here
$ lookup-routing --list --ssl # lists paths routing system that use https


And third, you can get a quick summary of stats by running
lookup-routing --stats


A quick reminder of which arguments to use is available by running:
lookup-routing --help

Very detailed usage instructions can be found by running:
lookup-routing --help --verbose


If you haven't already installed the dev tools yet, see the Dev Tools wiki page. If you've installed the dev tools before, make sure to update your code, to pull in the changes.