avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [Fwd: Re: New AltProfile package]
Date Mon, 11 Mar 2002 04:07:04 GMT
Leif Mortenson wrote:
> Berin Loritsch wrote:
>>  > Basicly, the ProfilerManageable interface would have as its contract
>>  > that implementing classes
>>  > would need to be able to function whether the setProfilerManager 
>> method
>>  > was called or not.
>>  > But that the method would only be called during the object's
>>  > initialization phase.
>> Let's keep it in scratchpad just a little while longer, there are a
>> couple things to straighten out first.  Once we have a GUI that can
>> attach itself to an external JVM we can consider the move to the main
>> package.
> Sounds good.  It looks like there are still several issues that need to
> be worked out.  First off is the name change though.  Here is what I
> was thinking:
> packages:
> .altprofile => .instrument
> .altprofile.component => .instrument.component
> .altprofile.profiler => .instrument.instrumentor
> classes:
> Profilable => Instrumentable
> ProfilePoint => InstrumentPoint
> ProfilerManager => InstrumentorManager
> etc.
> Thoughts / opinions before I start changing things name-wise?  My
> only issue is that the names are a bit long and might be annoying
> to use after a while.  But I would not want to use abreviations.

It sounds good.  Avalon has lots of long names, but I don't want
to be terse either.

The ProfilerManager could be named InstrumentManager (saves two

>> The memory profilepoints should be default and part of the
>> ProfileManager, and not ProfileableComponentManager.  The PCM (when
>> integrated with the ECM) should worry about the ComponentHandlers
>> and other metadata that is specific to mananging components.
> That is the way it is now, so I agree :-)  While the PCM will be the
> mail user of the PM, I really want the PM to be indepentant of it.
> In addition to making it easy to be used elsewhere, it will also make
> it easier to move over to using things like the ContainerManager.

+1 all the way.

>> That way we can see that if results are not average, which side of the
>> equation they lay on.
> The problem is that this could not be done entirely in the chart.  If it
> was, then it would show the std of the data in the chart.  Depending on
> the ProfileSample.  This might be the MaxValues per sample over time.
> I think that is what is really needed is another ProfileSample type
> called StandardDeviationValueProfileSample or something.  It could track
> three sets of data.  The max, min and avg for each profile sample.  Then
> the LineChart could be modified to show all three sets of data maybe as
> for each point???

Sure, but let's focus on the other things first.  While this is a "nice
to have", it is not a must yet.

Sign Up for NetZero Platinum Today
Only $9.95 per month!

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message