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: API Tools Matrix
Date Mon, 26 Jan 2009 16:59:48 GMT
Sonal, thanks for this, it really helps to see which tools are going to
depend on which features. We'll just have to make sure that as the user
stories become more defined, we keep the matrix up to date as I can see it
being used as a guide to which underlying components can (and should be)
shared.

I'm going to see if I can produce a similar spreadsheet but for the initial
API which is going to be contributed to the project. I'll do the same as
you, create a Google spreadsheet and post out a link when I have something
for people to look at.

2009/1/26 Sonal Goyal <sonalgoyal4@gmail.com>

> Hi Adam,
>
> Is this what you had in mind? I have created a spreadsheet with some
> high level features, and color coded the features based on their type.
> I have filled in information for the explorers, let me know if this
> helps and we can add data for the other tools and refine the features
> further.
>
> http://spreadsheets.google.com/ccc?key=pBu-ROmH7LPskFEKN7el7Sg&inv=sonalgoyal4@gmail.com&t=3616608217759084208&guest
>
> Cheers,
> Sonal
>
>
> On Mon, Jan 26, 2009 at 3:41 PM, Adam Pilkington <
> pilkington.adam@googlemail.com> wrote:
>
> > Hi all, I've been thinking that it would be a good idea if we can
> construct
> > a matrix showing which tools use which part of the API, for example a
> > memory
> > analyser tool would require access to the areas of the API which deal
> with
> > the heap, whilst a tool for deadlock analysis would want to view
> > thread/monitor data. I see the advantages of this as being
> >
> > 1) When implementing the API we can see how much support is needed in
> order
> > to allow basic or full functionality for a given tool.
> > 2) The matrix will allow us to plan sensible engagement points with other
> > tools vendors (both commercial and open source) i.e. there is enough API
> > functionality available for them to be interested.
> >
> > I would envisage this as a page on our website that can be updated over
> > time.
> >
> > --
> > Regards
> >
> > Adam Pilkington
> >
>



-- 
Regards

Adam Pilkington

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