Trecx - why not store all data in the remote tracking store?

We are often asked: 'why not just get every tool in a WAFFLE to post its events to the remote tracking store'?

Our response is

• why store the same data twice? If the data is stored internally in an application then let us leave it there!
• tools that store their own tracking data may well have the notion of users having to be authorised to see the tracking data. It is not feaible to post this information to a remote store (as access permissions may be changed after the event). So we need to leave already collected data 'in place'.
• a target application may require less modification to be searched than it would to send its events to a 3rd party.
• in some cases (with closed source tools) it may only be possible to access the database and not the source code, ie, the database can be searched with no modifications the to the application that drives it. A facade could be written to do this.

http://bodington.org/wiki/index.php/Trecx:DesignIssues

We're also wondering about the query interface. We were going to use XQuery but then realised that interfacing XQuery with an arbitrary SQL database will be a large task way out of scope of trecx, so we're having a rethink.

We believe that the tracking store is not a complex piece of software; one of the cornerstones of Trecx is to keep things simple, ie, simple message structure, simple security, simple message format and simple RESTian WS interface.

We are intending to use Aspect Oriented programming to demo how 3rd party tools can be 'instrumented' to produce otherwise unavailable tracking data.