Yesterday, I learnt about Tx (LINQ to Logs and Traces) from This Week On Channel 9. The name suggest that it has overlap with my end-to-end example on LINQ to W3SVC log files. It turns out that the overlap is minimal.
Tx is a Microsoft Open Technologies project. The source code commit history suggest it was originally part Reactive Extension (Rx) developed by the Rx team and became an independent project a year ago. Tx heavily uses Rx.
The Tx project has a page on “When to use Tx?” and I will quote a portion of it below.
When NOT to use TxUse only LINQ-to-Objects when:
- There are no real-time feeds involved
- The data is already in memory (e.g. List <T>), or you are dealing with single file that is easy to parse - e.g. a text file, each line representing event of the same type.
Use only Reactive Extensions (Rx) when:
- There are real-time feeds (e.g. mouse moves)
- You need the same query to work on past history (e.g. file(s)) and real-time
- Each feed/file contains a single type of events, like T for IObservable<T>
When to use TxTx.Core adds the following new features to Rx:
- Support for Multiplexed sequences (single sequence containing events of different types in order of occurence). The simplest example of turning multiplexd sequence into type-specific Obseravable-s is the Demultiplexor
- Merging multiple input files in order of occurence - e.g. two log files
- Hereogeneous Inputs - e.g. queries across some log files (.evtx) and some traces (.etl)
- Single-pass-read to answer multiple queries on file(s)
- Scale in # of queries. This is side effect of the above, which applies to both real-time and single-read of past history
- Providing virtual time as per event timestamps. See TimeSource
- Support for both "Structured" (like database, or Rx) and "Timeline" mode (like most event-viewing tools)
The Tx W3CEnumerable.cs does have overlap with my implementation of log parser. I wish I had noticed the project earlier. In the future, I will try to align my project with Tx to make it easier to use them together. I just had an implementation of duct-typing so interoperating different types from the same idea should be easy.