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 characters). >> 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! http://my.netzero.net/s/signup?r=platinum&refcd=PT97 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
