Hi - On Tue, Aug 31, 2010 at 10:50:30AM -0400, Mathieu Desnoyers wrote:
> [...] The goal of the present document is to propose a trace format
> that will suit the needs [...]. It starts by doing an overview of
> the trace format, tracer and trace analyzer requirements to consider
> for a Common Trace Format proposal.
Was it your intent to limit this document to a listing of abstract
requirements, as opposed to proposing an actual file format?
> 1) Architecture
> This high-level model is meant to be an industry-wide, common model,
> fulfilling the tracing requirements. It is meant to be application-,
> architecture-, and language-agnostic.
> [...]
> - Metadata [...]
> - Metadata description language not imposed by standard
If the metadata is not given in a standard form, then how do envision
general trace analysis tools (those not hard-coded for some particular
trace source) working?
> * Requirements on the Tracers
> Higher-level tracer requirements that seem appropriate to support
> some of the trace format requirements stated above. [...]
The list that follows here appear to be wish-list performance
characteristics of the tracing infrastructure ("make it go fast" and
"use good transports"). How does it benefit the tracing *format*
specification to enumerate such particulars here?
> * Trace Analyzer Requirements
> [...]
Such requirements are specific to some particular tracing task. It
would not make sense to identify these items as normative. For
example, a trace analyzer tool that can consume the standard format
should not be deemed to violate the standard, if it merely can't grok
10GB files.
- FChE
pgpO2nEcQDEDb.pgp
Description: PGP signature
_______________________________________________ ltt-dev mailing list [email protected] http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
