Custom pluggable filters and/or input sources

Not all logfiles are in readable text formats, most notable:
- XML
- proprietary binary formats
proposal: create a transformation format (sort of an XMLT, but not only for XML files) so any binary files can be read if the user provides a correct transformation file for it.
I can imagine something like python's struct.unpack(fmt) but that would mainly work for the message text. Extracting the date and time stamp would be difficult. Wouldn't it be much more simple to make an executable that converts its stdin to stdout in .dblog format such that it can be piped into DebugView++?
Sounds good, maybe we can just define a name convention, so it works like a plugin, so it is still transparent to the user, just drag a file into debugview++ and it works.
c:> plugin.exe --info
fileextention: .log
c:> plugin.exe --indentify
Actually the more I think of it, the better this sounds, we could also remove the support for sockets from debugview++ and re-add it as a separate plugin project. The same goes for the dbgview-agent kernel messages support...
@djeedjay as discussed, we decided to try to implement a plugin-feature by adding DLL's that implement a COM interface but without registering the DLL.
Features:
- the plugin as logsource (input)
- the plugin as a include / exclude / highlight / clear filter (but not the other filters)
- the plugin should be able to add filters, focus a line by timestamp or index.
Question:
- how to pass configuration options to the plugin, for example: udp-socket listener needs to know what interface, address and port to listen for.
Idea's:
- Suppose I write a program and when I click a point in a graph on the application I want to focus a line near I certain timestamp in debugview++, could we do that with a plugin? I support we could use UDP messages to send commands to debugview++

I considered this often: add input (not view based) filter:
- this would be a dialog that looks like the View / Filter settings but it filters lines before they come in. (so they are lost forever, like in dbgview)
- in this dialog we could also add input-sources (the plugins)

This is just an idea, so the type 'UDP 21' does not actually make sense, we should have some way to parameterize the plugins
We should split this issue into two parts:
- native plugins, C++ dlls implemented in a formalized format
- custom input plugins, I have created issue #219 for this
for infra log files there *logconvert' tool available on the commandline
in DebugViewPP\plugins\cs\HttpMonitor there is a http-plugin concept