Marcus Crafter wrote:
> Hi Leif,
>
> Well, after a short interlude with our project work here, I was
> finally able to have a look at your altprofile code.
>
> Nice stuff. It's certainly a lot further advanced than the code
> I'd written. Well done.
>
> I've tried to get my head around your design, etc. Please tell
> me if the following analysis is right:
>
> -----------------------------------------------------------------
>
> The profile manager maintains a list of profilable objects,
> registered either automatically by the profilable component
> manager, or manually via a registerProfilable() method on the
> manager itself.
Correct.
>
> Each profilable exposes 0 to many profile points which maybe of
> type 'value', or 'counter'.
>
> Upon registration with the profile manager, a profilable proxy
> is created which manages profile point proxies across threadsafe
> and non thread safe components.
Correct.
> Profile point proxies let you register listener classes for
> updates from the profile points themselves. The listeners can be
> implementors of a lower level ProfilePointListener class, or
> high level Sample classes.
Almost. The ProfilePointListener is not meant to be implemented directly.
It is just the super class of the CounterProfilePointListener and
ValueProfilePointListener interfaces. Those two types of listeners can be
regestered with a ProfilePoint through the addCounterProfilePointListener
and addValueProfilePointListener methods of a ProfilePointDescriptor object.
The Samples are at a higher level and have their own ProfileSampleListener
interface for listeners which register with them.
> The profile manager can be configured to automatically create a
> set of listeners (samplers in this case) for particular profile points
> on a particular profilable. Samplers configured in this way can
> be accessed via the profile manager. The gui reporter essentially
> iterates through the list of available samplers when building
> it's menu's.
Correct.
> When profilables update their profile points, each listener is
> informed of the update, along the lines of the observer pattern.
>
> The profiler manager exposes an array of all profilable descriptor
> objects, which in turn expose an array of all profile point
> descriptor objects, which offer reporting tools a way at
> accessing the profilable objects this manager manages and
> registering listeners.
>
> -----------------------------------------------------------------
>
> Does this analysis sound right ? Is there anything I've missed ? I do
> have a few comments, but I want to make sure I've understood everything
> first. :-)
Yes that covers the main points.
Leif
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
