incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Pilkington" <pilkington.a...@googlemail.com>
Subject Re: Runtime and Process Explorers
Date Tue, 20 Jan 2009 09:23:16 GMT
Hi Sonal, I think that these are good suggestions to increase the usability,
and should be included in the explorer tools.With regards to the summary or
overview section, I think that we may be able to go a step further and
provide context sensitive help back to the relevant section of the JSR or
API JavaDoc which corresponds to the data item currently being explored.

Regards

Adam Pilkington

On Mon, Jan 19, 2009 at 9:41 AM, Sonal Goyal <sonalgoyal4@gmail.com> wrote:

> Hi Adam,
> Thanks for your email and the detailed explanation of the tool. I have the
> following suggestions:
>
> 1. It may be useful to be able to link to source code.
> 2. I think if we could include an overview or summary section in the tool,
> it will enhance the usability.
>
> Thanks and Regards,
> Sonal
>
>
> On Wed, Jan 14, 2009 at 10:41 PM, Adam Pilkington <
> pilkington.adam@googlemail.com> wrote:
>
> > Hi all, my name is Adam Pilkington and I'm a member of Steve's team. I'm
> > using this post to start a thread for discussing how the explorer tools
> > (that's the Process and Runtime Explorers) should be developed.
> >
> > I think that the use cases are going to be very much along the lines
> > outlined by Steve in his original post, particularly as we have
> identified
> > the Runtime Investigator as a separate tool.
> >
> > *Use Cases*
> > 1) Dump exploration : given a particular dump file, then you want to
> wander
> > through all the available data seeing what is there.
> > 2) Data verification : given a particular dump file, then you wish to
> > verify
> > the contents of the dump match your expectations. A simple example of
> this
> > would be to check the presence of a certain object instance on the heap,
> > and
> > possibly that the field values were correct.
> >
> > *Characteristics*
> > From an API perspective I think that these tools will expect the
> following
> > characteristics
> > 1)  Lightweight - only deal with what is being requested by the user.
> This
> > should ensure a fast startup and subsequent navigation.
> > 2) Random access of the dump file (if possible we want to avoid
> > sequentially
> > iterating over data items). This will also cover the aspects of dealing
> > with
> > large quantities of data.
> >
> > *Functional Requirements
> > *The following is an initial list of common tools functionality which
> will
> > be required to support the use cases.
> > 1) Data type specification : the ability to tell the UI to display the
> data
> > at a given address as a specific data type e.g. this address represents
> the
> > start of a null terminated string.
> > 2) Data overlays : the ability to override the actual byte values
> contained
> > in a dump with user defined values and have the UI work with the updated
> > value. This means that you would be able to potentially fix corrupt
> > structures or lists by specifying the correct values. You should then be
> > able to save and reload these overlays as required.
> > 3) Automatic determination of dump type
> > 4) The ability to launch other tools, such as the Runtime Investigator,
> > from
> > the explorer. This can be simply launching the tool or launching with a
> set
> > of command line options which make sense within the current explorer
> > context.e.g. the explorer shows a large heap occupancy, so you launch the
> > Runtime Investigator which starts a heap occupancy analysis.
> >
> > Ultimately these tools are going to be driven by the user interface.
> > Initially we may aim to present this as a standard two pane, tree view
> type
> > explorer, however as we come to use this ourselves and find that the UI
> is
> > lacking, then further requirements may come to light.
> >
> > Are there any thoughts on other UI paradigms or use cases that we may
> wish
> > to support in the explorer tools ?
> >
> > Regards
> >
> > Adam Pilkington
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message