Re: [linuxtools-dev] TMF Hack-a-thon kickoff: file open dialog RFC

[Aaron Spear <aspear@xxxxxxxxxx>]

----- Original Message -----
> On 13-12-12 10:55 AM, Aaron Spear wrote:
> > Hi Michel,
> >
> > I think that the "This is a file type that I handle" return value would be
> > useful if it was not just boolean, but rather a rank of some sort. [...]
> 
> Hi Aaron,
> 
> The idea of rank, or "priority", is pretty good! It's so simple too, I
> wonder why we didn't think about it. We have added a kind of
> auto-detection already (see below), but to handle cases where a trace
> can be both a "Generic CTF Trace" and a "LTTng Kernel Trace", we
> resorted to funky reflection calls to check if one type is a subtype of
> the other one, to filter the base type out. With integer priorities,
> this becomes much more simple.

Good!  I implemented exactly this idea in a previous debugger product I developed for automatically identifying ELF files and which plugin should be used to handle the symbolic decoding for a given file.  We had a generic elf decoder that could read generic elf files and handle standard dwarf debug info and such.  Then there were other derived ones that knew how to handle quirks in certain debug formats or architectures (e.g. the RealView compiler for ARM or whatever).  The files themselves were passed to a reader/decoder factory which studied the file and then calculated a rank integer that it returned.  if the file was a valid elf file it would add one. If the file was an elf file with supported debug info it would increment again.  In derived readers/decoders it would take the base classes value and then additionally it would add more to the integer value if the architecture matched and so on.  This choice of auto identified "factory to use" was then cached per file path so that this process was only done once for a file (which makes lots of sense for edit/compile/debug cycles, but maybe less so for tracing)

Note that I did something similar to this in the extensions that I did earlier to TMF (the ones that I didn't follow through with properly submitting...)  In that extension there was the possibility of adding any number of possible data driven state system providers that automatically check if they can support the given trace type.  The factories for these state providers came through extension point, which is a nice way to do it since then the state systems can come from any plugin.

cheers,
Aaron