They would be automatically selected from the extension of the log file names. That way we can support multiple log file formats. This is similar to the mechanism for the Import and Report plugins, so we'll just reuse that.
They would receive messages in real time, just like the UI plugins, so again we can reuse that (it's as simple as instancing a new Notifier).
The tricky parts would be:
Exporting logs from a database: this would probably require a dedicated command, and some hacks in the Orchestrator. A quick cop out would be to have a magic Report plugin that loads the log lines from the database and feeds them to the Log plugins. But that's just nasty coding. A less horrible hack would be to put the code that loads the old logs from the database in the base class, to make them compatible with the Report plugin interface, so we can load them as if they were Report plugins.
Deciding if the Log plugins should run alongside the Orchestrator, in a dedicated fork, or each one in its own fork.
They would be automatically selected from the extension of the log file names. That way we can support multiple log file formats. This is similar to the mechanism for the Import and Report plugins, so we'll just reuse that.
They would receive messages in real time, just like the UI plugins, so again we can reuse that (it's as simple as instancing a new Notifier).
The tricky parts would be: