| commit | ad8c1c896fe540063b2008a7333ca7f92f646917 | |
| author | Ethereal <ethereal.visage@gmail.com> | |
| Thu, 24 Feb 2011 18:54:48 +0000 (24 11:54 -0700) | ||
| committer | Ethereal <ethereal.visage@gmail.com> | |
| Thu, 24 Feb 2011 18:54:48 +0000 (24 11:54 -0700) | ||
| tree | e9a4caac9ab681a3e289fdbab37bcecf1ba52783 | treesnapshot (tar.gz zip) |
| parent | e10aa8c55633a2ee59f7f9043954ffc262f75975 | commitdiff |
I am beginning to question the need for a marshaller.
The only real use that I can see for the marshaller is for symbol resolution.
And, if all goes as planned, symbol resolution will be provided by a Monitor-
supplied module, e.g. doing the processing within the Monitor itself. The
symbol data can simply be supplied to the Visualizer for the Visualizer to
use, then an R-tree can be used to do the symbol lookups . . .
If I am correct, and the marshaller is not required, then it will make the
implementation of the monitor (and the modules!) that much cleaner.
The only real use that I can see for the marshaller is for symbol resolution.
And, if all goes as planned, symbol resolution will be provided by a Monitor-
supplied module, e.g. doing the processing within the Monitor itself. The
symbol data can simply be supplied to the Visualizer for the Visualizer to
use, then an R-tree can be used to do the symbol lookups . . .
If I am correct, and the marshaller is not required, then it will make the
implementation of the monitor (and the modules!) that much cleaner.