+The '''event type''' must implement an ''ITmfEvent'' or extend a class that
+implements an ''ITmfEvent''. Typically it will extend ''TmfEvent''. The event
+type must contain all the data of an event.
+
+The '''trace reader''' must be of an ''ITmfTrace'' type. The ''TmfTrace'' class
+will supply many background operations so that the reader only needs to
+implement certain functions.
+
+The '''trace context''' can be seen as the internals of an iterator. It is
+required by the trace reader to parse events as it iterates the trace and to
+keep track of its rank and location. It can have a timestamp, a rank, a file
+position, or any other element, it should be considered to be ephemeral.
+
+The '''trace location''' is an element that is cloned often to store
+checkpoints, it is generally persistent. It is used to rebuild a context,
+therefore, it needs to contain enough information to unambiguously point to one
+and only one event. Finally the ''tracetype'' plug-in extension associates a
+given trace, non-programmatically to a trace type for use in the UI.
+
+== Optional Trace Type Attributes ==
+
+After defining the trace type as described in the previous chapters it is
+possible to define optional attributes for the trace type.
+
+=== Default Editor ===
+
+The '''defaultEditor''' attribute of the '''org.eclipse.linuxtools.tmf.ui.tracetypeui'''
+extension point allows for configuring the editor to use for displaying the
+events. If omitted, the ''TmfEventsEditor'' is used as default.
+
+To configure an editor, first add the '''defaultEditor''' attribute to the trace
+type in the extension definition. This can be done by selecting the trace type
+in the plug-in manifest editor. Then click the right mouse button and select
+'''New -> defaultEditor''' in the context sensitive menu. Then select the newly
+added attribute. Now you can specify the editor id to use on the right side of
+the manifest editor. For example, this attribute could be used to implement an
+extension of the class ''org.eclipse.ui.part.MultiPageEditor''. The first page
+could use the ''TmfEventsEditor''' to display the events in a table as usual and
+other pages can display other aspects of the trace.
+
+=== Events Table Type ===
+
+The '''eventsTableType''' attribute of the '''org.eclipse.linuxtools.tmf.ui.tracetypeui'''
+extension point allows for configuring the events table class to use in the
+default events editor. If omitted, the default events table will be used.
+
+To configure a trace type specific events table, first add the
+'''eventsTableType''' attribute to the trace type in the extension definition.
+This can be done by selecting the trace type in the plug-in manifest editor.
+Then click the right mouse button and select '''New -> eventsTableType''' in the
+context sensitive menu. Then select the newly added attribute and click on
+''class'' on the right side of the manifest editor. The new class wizard will
+open. The ''superclass'' field will be already filled with the class ''org.eclipse.tracecompass.tmf.ui.viewers.events.TmfEventsTable''.
+
+By using this attribute, a table with different columns than the default columns
+can be defined. See the class
+''org.eclipse.tracecompass.internal.gdbtrace.ui.views.events.GdbEventsTable''
+for an example implementation.
+
+== Other Considerations ==
+
+Other views and components may provide additional features that are active only
+when the event or trace type class implements certain additional interfaces.
+
+=== Collapsing of repetitive events ===
+
+By implementing the interface
+''org.eclipse.tracecompass.tmf.core.event.collapse.ITmfCollapsibleEvent'' the
+event table will allow to collapse repetitive events by selecting the menu item
+'''Collapse Events''' after pressing the right mouse button in the table.
+
+== Best Practices ==
+
+* Do not load the whole trace in RAM, it will limit the size of the trace that can be read.
+* Reuse as much code as possible, it makes the trace format much easier to maintain.
+* Use Eclipse's editor instead of editing the XML directly.
+* Do not forget Java supports only signed data types, there may be special care needed to handle unsigned data.
+* If the support for your trace has custom UI elements (like icons, views, etc.), split the core and UI parts in separate plugins, named identically except for a ''.core'' or ''.ui'' suffix.
+** Implement the ''tmf.core.tracetype'' extension in the core plugin, and the ''tmf.ui.tracetypeui'' extension in the UI plugin if applicable.