![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png){kind=small}
Entry tags:
LJ::EventLogRecord and LJ::EventLogSink: remove completely or finish implementation?
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?
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?