Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » COSMOS » BtM Use Cases
BtM Use Cases [message #3118] Mon, 30 October 2006 15:07 Go to next message
Oliver E Cole is currently offline Oliver E Cole
Messages: 22
Registered: July 2009
Junior Member
One of the component areas of the COSMOS effort is BtM: Build to
Manage. IBM is contributing the original code for BtM to eclipse (some
has already been contributed and more is on the way)....

For the uninitiated, a good web page to start with is:

http://www-128.ibm.com/developerworks/eclipse/btm/

We are now in the process of understanding what is there already and
are doing that with use cases. The first iteration of these use cases
can be found at:

http://wiki.eclipse.org/index.php/Build_to_Manage_use_cases

Let the discussions begin.....
Re: BtM Use Cases [message #3150 is a reply to message #3118] Mon, 30 October 2006 15:22 Go to previous messageGo to next message
Brian Vetter is currently offline Brian Vetter
Messages: 74
Registered: July 2009
Member
The developerworks link appears to be broken. I get an error 400 Bad
Request.

Brian

Oliver E Cole wrote:
>
> One of the component areas of the COSMOS effort is BtM: Build to
> Manage. IBM is contributing the original code for BtM to eclipse (some
> has already been contributed and more is on the way)....
>
> For the uninitiated, a good web page to start with is:
>
> http://www-128.ibm.com/developerworks/eclipse/btm/
>
> We are now in the process of understanding what is there already and
> are doing that with use cases. The first iteration of these use cases
> can be found at:
>
> http://wiki.eclipse.org/index.php/Build_to_Manage_use_cases
>
> Let the discussions begin.....
Re: BtM Use Cases [message #3184 is a reply to message #3150] Mon, 30 October 2006 15:24 Go to previous messageGo to next message
Brian Vetter is currently offline Brian Vetter
Messages: 74
Registered: July 2009
Member
Nevermind, it works now. Must have been a temporary problem.

Brian

Brian Vetter wrote:
> The developerworks link appears to be broken. I get an error 400 Bad
> Request.
>
> Brian
>
> Oliver E Cole wrote:
>>
>> One of the component areas of the COSMOS effort is BtM: Build to
>> Manage. IBM is contributing the original code for BtM to eclipse
>> (some has already been contributed and more is on the way)....
>>
>> For the uninitiated, a good web page to start with is:
>>
>> http://www-128.ibm.com/developerworks/eclipse/btm/
>>
>> We are now in the process of understanding what is there already
>> and are doing that with use cases. The first iteration of these use
>> cases can be found at:
>>
>> http://wiki.eclipse.org/index.php/Build_to_Manage_use_cases
>>
>> Let the discussions begin.....
BtM Use Case Meeting: Nov 1 3:00pm EST [message #3284 is a reply to message #3118] Mon, 30 October 2006 23:32 Go to previous messageGo to next message
Mark Weitzel is currently offline Mark Weitzel
Messages: 78
Registered: July 2009
Member
Please join us for a discussion on the Built To Manage use cases.
Wednesday November 1, 2006
3:00 - 4:00pm EST
Call in: 888 241 8547 Pass Code 999451



Oliver E Cole wrote:
>
> One of the component areas of the COSMOS effort is BtM: Build to
> Manage. IBM is contributing the original code for BtM to eclipse (some
> has already been contributed and more is on the way)....
>
> For the uninitiated, a good web page to start with is:
>
> http://www-128.ibm.com/developerworks/eclipse/btm/
>
> We are now in the process of understanding what is there already and
> are doing that with use cases. The first iteration of these use cases
> can be found at:
>
> http://wiki.eclipse.org/index.php/Build_to_Manage_use_cases
>
> Let the discussions begin.....
Re: BtM Use Cases [message #3550 is a reply to message #3184] Thu, 09 November 2006 09:41 Go to previous messageGo to next message
Oliver E Cole is currently offline Oliver E Cole
Messages: 22
Registered: July 2009
Junior Member
Ok, I have been thinking about this BtM stuff a bunch. I have a
pretty good grasp of what it does now (from IBM). Now the questions is
"What should it mean in the context of eclipse?"

Vasya (at OCS) and I have kicked this around some, until finally I
figured out why I am having a hard time.

BtM is designed to help the software development team make
applications manageable. Ok, what does that mean, the term "Manageable"?

It means operations. It means that the application is easier to
"maintain" during its operation. Now my problem (is and has been) that
I don't see how we can "connect" with operations. (I am going to use
the terms monitoring and managing pretty much interchangably here).

The current BtM is designed to support "instrumentation" being
injected into the application. It can do ARM, CBE and JMX. But where
does that instrumentation write its data when the application is
running? Currently, we have no "runtime" to support BtM. Of course,
lots of vendors support different management frameworks, but does that
mean that BtM would require a proprietary runtime framework to do anything?

Also, there not a single set of monitoring standards that all
monotiring/managing solutions would use. So, does this mean that each
monitoring "vendor" has to have his own BtM? Does that mean that COSMOS
BtM has to target a "free" monitoring solution? If so, which one?

So, a BtM "plan" has to have a data colletion (and viewing)
plan for the operation system before we can call it a plan. Am I wrong
here?

CBE seems to be the lowest hanging fruit. tptp already has a
CBE log analyzer. Perhaps we come out with packages to "CBE enable"
sufficient middle ware (maybe the JLAMP stack) so that the CBE standard
gets a push. Yes, users would need to collect the CBE log files
themselves in the operational system, but that is not too daunting.

ARM is the next easiest to do as a standard. tptp has simple
ARM agents, but the tptp ARM implementation is quite simple and not
intended for operations. Again, perhaps we could push for a set of ARM
instrumentation for JLAMP as a means to promote the standard and a
sufficient set of ARM agents to collect it.

The JMX standard looks hard to promote without a lot more
work. Am I missing something here? Yah, we can support JMX insertion
of instrumentation, but the collecting and viewing of that data at
runtime seems to require a bunch more infrastructure than COSMOS can
commit to.

BtM inserts instrumentation. It also needs to collect the
data from that instrumentation. Looks like CBE and ARM are the best
possibilities to focus on.
Re: BtM Use Cases [message #3615 is a reply to message #3550] Thu, 09 November 2006 14:56 Go to previous messageGo to next message
Brian Vetter is currently offline Brian Vetter
Messages: 74
Registered: July 2009
Member
Oliver E Cole wrote:
>
> The JMX standard looks hard to promote without a lot more
> work. Am I missing something here? Yah, we can support JMX insertion
> of instrumentation, but the collecting and viewing of that data at
> runtime seems to require a bunch more infrastructure than COSMOS can
> commit to.

I'm not sure I understand this comment. Most every commercial Java
management tool that exists can collect JMX instrumentation from a
running application server. Many of the commercial J2xx platforms have
consoles that can managed JMX instrumented applications and most use JMX
to instrument and manage themselves.

In fact, there are several open source JMX management consoles. MC4J is
even licensed under Apache and supports JSR 160 and its remote JMX APIs
and Sun's reference implementation.

So I'm not quite sure what you are saying that it will require a lot
more work.

> BtM inserts instrumentation. It also needs to collect the
> data from that instrumentation. Looks like CBE and ARM are the best
> possibilities to focus on.

In the case J2xx applications, it isn't clear to me that JMX isn't just
as easy and just as valuable.

Brian
Re: BtM Use Cases [message #3681 is a reply to message #3615] Sat, 11 November 2006 15:55 Go to previous messageGo to next message
Oliver E Cole is currently offline Oliver E Cole
Messages: 22
Registered: July 2009
Junior Member
I should be more to the point...

I am trying to come up with the use cases for BtM. One use case is
the current BtM one, where one uses BtM to perform the actual
instrumentation. The zillions of other factors (collecting the data and
getting it back to be viewed) to actually monitor, are ignored. I will
call the the "instrument" use case.

One question that should be put forward wrt the instrument use case
is what: What technologies should BtM support? So far, it supports
ARM, CBE, JMX, all for Java .NET capabilities are coming soon.

The use cases given by David Skeen document the above.

The is another set of use cases however that I would like to kick
around: BtM would embrace the whole end-to-end process. For now, I'll
call these the "end-to-end" use cases. An end-to-end use case starts
with the user wanting to "manage" his application with one of (ARM, CBE,
JMX) and goes all the way through actually viewing the data.

Right now, the BtM toolkit does the complete use case for using ARM
to do method level Java profiling, but this is not the compelling use
case for ARM, the compelling use for ARM is a more complicated use case.

But I would like to discuss other end-to-end use cases that may be
candidates for BtM. If we are to get adoption for these, we need to
make it simple to get the data from the standard, not just implement the
standard ;)

Here are some thoughts:

ARM: The real benefit of ARM is in transaction tracking. BtM could
embrace the ene-to-end use case of building ARMed applications and
viewing ARM data.

CBE: tptp already has a log analyzer. It doesn't sound too hard to
have BTM to address the end-to-end use case of Building CBE into the
application. Log file collection would need to be addressed, but this
can be pretty simple I think.

JMX: I am on shakier ground here, I need to read up more about the
current state of things in the JMX world and what standards are
prevelant. An obvious possibility is the end-to-end use case of
building in and monitoring JMX data, but I have the feeling that this is
a big effort. Additionally, there are already some open stuff out
there. Can we build them into our end-to-end use case? Or would they
have to commit to the EPL? I gotta read up more on JMX I think...

Lastly, there are probably some use cases that are in between
instrument and end-to-end.


--oec


Brian Vetter wrote:
> Oliver E Cole wrote:
>
>>
>> The JMX standard looks hard to promote without a lot more
>> work. Am I missing something here? Yah, we can support JMX
>> insertion of instrumentation, but the collecting and viewing of that
>> data at runtime seems to require a bunch more infrastructure than
>> COSMOS can commit to.
>
>
> I'm not sure I understand this comment. Most every commercial Java
> management tool that exists can collect JMX instrumentation from a
> running application server. Many of the commercial J2xx platforms have
> consoles that can managed JMX instrumented applications and most use JMX
> to instrument and manage themselves.
>
> In fact, there are several open source JMX management consoles. MC4J is
> even licensed under Apache and supports JSR 160 and its remote JMX APIs
> and Sun's reference implementation.
>
> So I'm not quite sure what you are saying that it will require a lot
> more work.
>
>> BtM inserts instrumentation. It also needs to collect the
>> data from that instrumentation. Looks like CBE and ARM are the best
>> possibilities to focus on.
>
>
> In the case J2xx applications, it isn't clear to me that JMX isn't just
> as easy and just as valuable.
>
> Brian
Meeting Notes BtM Nov 15th. [message #4408 is a reply to message #3118] Thu, 16 November 2006 09:52 Go to previous message
Oliver E Cole is currently offline Oliver E Cole
Messages: 22
Registered: July 2009
Junior Member
First, I would like to personally thank those that participated in
the BtM call. It was very productive and we are making good progress
now (sorry for the slow start...)

Matt Ming, Dave Skeen, Mark Weitzel, Vasya Gorshkov and Oliver Cole
were dialed in (these meetings are every Wednesday at 1PM EST for one hour).

If anyone desires to get involved or has any questions, contact
Oliver or post...

First order of discussion was the current BtM value proposition of
instrumentation. All agreed that it should remain, but SNMP should be
added to the list of standards that should be incorporated. No specific
enhancements were proposed to the current functionality. Dave Skeens
current use cases are adequate for this.

Second order, end-to-end use cases were discussed. As it turns
out end-to-end use cases may be closer than we think for the three
technologies ARM, CEB (WEF) and JMX, if we embrace the existing tptp
functionality. It was agreed that a main point of BtM is to promote
standards rather than provide a production level product on those
standards, but to do that people had to find the standards easy to use
in a pre-production environment, and an end-to-end use case is the way
to do that.

It was decided that we first needed to get a firm understanding
of what is already in tptp/BtM, and Matt volunteered to do a Web
demonstration of the existing end-to-end functionality in the next
wednesday BtM meeting. (Matt, OCS has a web broadcasting thing that we
can set up easily for you, just let me know).

There is a sense that there are two deadlines for our work:
March and June. We all agree that a synergy with SML is appropriate
but March is probably too early to plan on something being implemented
for BtM, but June seems doable.

So, at a high level, the idea is to see what is already there
and focus on ease of use for the (pretty much?) existing end-to-end use
cases for BtM/tptp for the three main uses cases of ARM, CBE and JMX for
March. SNMP support still needs to be investigated.

Action items: Dave Skeen, who will get a feeling from IBM as to
whether IBM would consider enahancing the tptp ARM agents/infrastructure
as infringing too much on production.

Matt Ming: have a web demo next week of the
existing capablities in BtM in an end to end scenario.

I think it is important that we not miss any existing
functionality in eclipse/tptp, alphaworks, developerworks, etc. There is
probably a lot we can leverage. As we go forward, the BtM effort (me)
should make sure that we get many people's input, even if they are not
part of the team specifically. I am always surprised how talking to
someone "related" to an effort can yield excellent nuggets of what exists.

For now, let's use the Kevin Bacon approach and all please
identify people that should be included and (as appropriate) I will take
the action item to grovel to them for some of their time for their
review. Feel free to invite guest presenters to the Wednesdays BtM
meetings.

Next call, Wednesday at 1PM at the same dial in specificed
elsewhere in the newsgroup. At any time, feel free to email me or get
me on the phone.....
Re: BtM Use Cases [message #567466 is a reply to message #3118] Mon, 30 October 2006 15:22 Go to previous message
Brian Vetter is currently offline Brian Vetter
Messages: 74
Registered: July 2009
Member
The developerworks link appears to be broken. I get an error 400 Bad
Request.

Brian

Oliver E Cole wrote:
>
> One of the component areas of the COSMOS effort is BtM: Build to
> Manage. IBM is contributing the original code for BtM to eclipse (some
> has already been contributed and more is on the way)....
>
> For the uninitiated, a good web page to start with is:
>
> http://www-128.ibm.com/developerworks/eclipse/btm/
>
> We are now in the process of understanding what is there already and
> are doing that with use cases. The first iteration of these use cases
> can be found at:
>
> http://wiki.eclipse.org/index.php/Build_to_Manage_use_cases
>
> Let the discussions begin.....
Re: BtM Use Cases [message #567494 is a reply to message #3150] Mon, 30 October 2006 15:24 Go to previous message
Brian Vetter is currently offline Brian Vetter
Messages: 74
Registered: July 2009
Member
Nevermind, it works now. Must have been a temporary problem.

Brian

Brian Vetter wrote:
> The developerworks link appears to be broken. I get an error 400 Bad
> Request.
>
> Brian
>
> Oliver E Cole wrote:
>>
>> One of the component areas of the COSMOS effort is BtM: Build to
>> Manage. IBM is contributing the original code for BtM to eclipse
>> (some has already been contributed and more is on the way)....
>>
>> For the uninitiated, a good web page to start with is:
>>
>> http://www-128.ibm.com/developerworks/eclipse/btm/
>>
>> We are now in the process of understanding what is there already
>> and are doing that with use cases. The first iteration of these use
>> cases can be found at:
>>
>> http://wiki.eclipse.org/index.php/Build_to_Manage_use_cases
>>
>> Let the discussions begin.....
BtM Use Case Meeting: Nov 1 3:00pm EST [message #567568 is a reply to message #3118] Mon, 30 October 2006 23:32 Go to previous message
Mark Weitzel is currently offline Mark Weitzel
Messages: 78
Registered: July 2009
Member
Please join us for a discussion on the Built To Manage use cases.
Wednesday November 1, 2006
3:00 - 4:00pm EST
Call in: 888 241 8547 Pass Code 999451



Oliver E Cole wrote:
>
> One of the component areas of the COSMOS effort is BtM: Build to
> Manage. IBM is contributing the original code for BtM to eclipse (some
> has already been contributed and more is on the way)....
>
> For the uninitiated, a good web page to start with is:
>
> http://www-128.ibm.com/developerworks/eclipse/btm/
>
> We are now in the process of understanding what is there already and
> are doing that with use cases. The first iteration of these use cases
> can be found at:
>
> http://wiki.eclipse.org/index.php/Build_to_Manage_use_cases
>
> Let the discussions begin.....
Re: BtM Use Cases [message #567744 is a reply to message #3184] Thu, 09 November 2006 09:41 Go to previous message
Oliver E Cole is currently offline Oliver E Cole
Messages: 22
Registered: July 2009
Junior Member
Ok, I have been thinking about this BtM stuff a bunch. I have a
pretty good grasp of what it does now (from IBM). Now the questions is
"What should it mean in the context of eclipse?"

Vasya (at OCS) and I have kicked this around some, until finally I
figured out why I am having a hard time.

BtM is designed to help the software development team make
applications manageable. Ok, what does that mean, the term "Manageable"?

It means operations. It means that the application is easier to
"maintain" during its operation. Now my problem (is and has been) that
I don't see how we can "connect" with operations. (I am going to use
the terms monitoring and managing pretty much interchangably here).

The current BtM is designed to support "instrumentation" being
injected into the application. It can do ARM, CBE and JMX. But where
does that instrumentation write its data when the application is
running? Currently, we have no "runtime" to support BtM. Of course,
lots of vendors support different management frameworks, but does that
mean that BtM would require a proprietary runtime framework to do anything?

Also, there not a single set of monitoring standards that all
monotiring/managing solutions would use. So, does this mean that each
monitoring "vendor" has to have his own BtM? Does that mean that COSMOS
BtM has to target a "free" monitoring solution? If so, which one?

So, a BtM "plan" has to have a data colletion (and viewing)
plan for the operation system before we can call it a plan. Am I wrong
here?

CBE seems to be the lowest hanging fruit. tptp already has a
CBE log analyzer. Perhaps we come out with packages to "CBE enable"
sufficient middle ware (maybe the JLAMP stack) so that the CBE standard
gets a push. Yes, users would need to collect the CBE log files
themselves in the operational system, but that is not too daunting.

ARM is the next easiest to do as a standard. tptp has simple
ARM agents, but the tptp ARM implementation is quite simple and not
intended for operations. Again, perhaps we could push for a set of ARM
instrumentation for JLAMP as a means to promote the standard and a
sufficient set of ARM agents to collect it.

The JMX standard looks hard to promote without a lot more
work. Am I missing something here? Yah, we can support JMX insertion
of instrumentation, but the collecting and viewing of that data at
runtime seems to require a bunch more infrastructure than COSMOS can
commit to.

BtM inserts instrumentation. It also needs to collect the
data from that instrumentation. Looks like CBE and ARM are the best
possibilities to focus on.
Re: BtM Use Cases [message #567791 is a reply to message #3550] Thu, 09 November 2006 14:56 Go to previous message
Brian Vetter is currently offline Brian Vetter
Messages: 74
Registered: July 2009
Member
Oliver E Cole wrote:
>
> The JMX standard looks hard to promote without a lot more
> work. Am I missing something here? Yah, we can support JMX insertion
> of instrumentation, but the collecting and viewing of that data at
> runtime seems to require a bunch more infrastructure than COSMOS can
> commit to.

I'm not sure I understand this comment. Most every commercial Java
management tool that exists can collect JMX instrumentation from a
running application server. Many of the commercial J2xx platforms have
consoles that can managed JMX instrumented applications and most use JMX
to instrument and manage themselves.

In fact, there are several open source JMX management consoles. MC4J is
even licensed under Apache and supports JSR 160 and its remote JMX APIs
and Sun's reference implementation.

So I'm not quite sure what you are saying that it will require a lot
more work.

> BtM inserts instrumentation. It also needs to collect the
> data from that instrumentation. Looks like CBE and ARM are the best
> possibilities to focus on.

In the case J2xx applications, it isn't clear to me that JMX isn't just
as easy and just as valuable.

Brian
Re: BtM Use Cases [message #567853 is a reply to message #3615] Sat, 11 November 2006 15:55 Go to previous message
Oliver E Cole is currently offline Oliver E Cole
Messages: 22
Registered: July 2009
Junior Member
I should be more to the point...

I am trying to come up with the use cases for BtM. One use case is
the current BtM one, where one uses BtM to perform the actual
instrumentation. The zillions of other factors (collecting the data and
getting it back to be viewed) to actually monitor, are ignored. I will
call the the "instrument" use case.

One question that should be put forward wrt the instrument use case
is what: What technologies should BtM support? So far, it supports
ARM, CBE, JMX, all for Java .NET capabilities are coming soon.

The use cases given by David Skeen document the above.

The is another set of use cases however that I would like to kick
around: BtM would embrace the whole end-to-end process. For now, I'll
call these the "end-to-end" use cases. An end-to-end use case starts
with the user wanting to "manage" his application with one of (ARM, CBE,
JMX) and goes all the way through actually viewing the data.

Right now, the BtM toolkit does the complete use case for using ARM
to do method level Java profiling, but this is not the compelling use
case for ARM, the compelling use for ARM is a more complicated use case.

But I would like to discuss other end-to-end use cases that may be
candidates for BtM. If we are to get adoption for these, we need to
make it simple to get the data from the standard, not just implement the
standard ;)

Here are some thoughts:

ARM: The real benefit of ARM is in transaction tracking. BtM could
embrace the ene-to-end use case of building ARMed applications and
viewing ARM data.

CBE: tptp already has a log analyzer. It doesn't sound too hard to
have BTM to address the end-to-end use case of Building CBE into the
application. Log file collection would need to be addressed, but this
can be pretty simple I think.

JMX: I am on shakier ground here, I need to read up more about the
current state of things in the JMX world and what standards are
prevelant. An obvious possibility is the end-to-end use case of
building in and monitoring JMX data, but I have the feeling that this is
a big effort. Additionally, there are already some open stuff out
there. Can we build them into our end-to-end use case? Or would they
have to commit to the EPL? I gotta read up more on JMX I think...

Lastly, there are probably some use cases that are in between
instrument and end-to-end.


--oec


Brian Vetter wrote:
> Oliver E Cole wrote:
>
>>
>> The JMX standard looks hard to promote without a lot more
>> work. Am I missing something here? Yah, we can support JMX
>> insertion of instrumentation, but the collecting and viewing of that
>> data at runtime seems to require a bunch more infrastructure than
>> COSMOS can commit to.
>
>
> I'm not sure I understand this comment. Most every commercial Java
> management tool that exists can collect JMX instrumentation from a
> running application server. Many of the commercial J2xx platforms have
> consoles that can managed JMX instrumented applications and most use JMX
> to instrument and manage themselves.
>
> In fact, there are several open source JMX management consoles. MC4J is
> even licensed under Apache and supports JSR 160 and its remote JMX APIs
> and Sun's reference implementation.
>
> So I'm not quite sure what you are saying that it will require a lot
> more work.
>
>> BtM inserts instrumentation. It also needs to collect the
>> data from that instrumentation. Looks like CBE and ARM are the best
>> possibilities to focus on.
>
>
> In the case J2xx applications, it isn't clear to me that JMX isn't just
> as easy and just as valuable.
>
> Brian
Meeting Notes BtM Nov 15th. [message #568036 is a reply to message #3118] Thu, 16 November 2006 09:52 Go to previous message
Oliver E Cole is currently offline Oliver E Cole
Messages: 22
Registered: July 2009
Junior Member
First, I would like to personally thank those that participated in
the BtM call. It was very productive and we are making good progress
now (sorry for the slow start...)

Matt Ming, Dave Skeen, Mark Weitzel, Vasya Gorshkov and Oliver Cole
were dialed in (these meetings are every Wednesday at 1PM EST for one hour).

If anyone desires to get involved or has any questions, contact
Oliver or post...

First order of discussion was the current BtM value proposition of
instrumentation. All agreed that it should remain, but SNMP should be
added to the list of standards that should be incorporated. No specific
enhancements were proposed to the current functionality. Dave Skeens
current use cases are adequate for this.

Second order, end-to-end use cases were discussed. As it turns
out end-to-end use cases may be closer than we think for the three
technologies ARM, CEB (WEF) and JMX, if we embrace the existing tptp
functionality. It was agreed that a main point of BtM is to promote
standards rather than provide a production level product on those
standards, but to do that people had to find the standards easy to use
in a pre-production environment, and an end-to-end use case is the way
to do that.

It was decided that we first needed to get a firm understanding
of what is already in tptp/BtM, and Matt volunteered to do a Web
demonstration of the existing end-to-end functionality in the next
wednesday BtM meeting. (Matt, OCS has a web broadcasting thing that we
can set up easily for you, just let me know).

There is a sense that there are two deadlines for our work:
March and June. We all agree that a synergy with SML is appropriate
but March is probably too early to plan on something being implemented
for BtM, but June seems doable.

So, at a high level, the idea is to see what is already there
and focus on ease of use for the (pretty much?) existing end-to-end use
cases for BtM/tptp for the three main uses cases of ARM, CBE and JMX for
March. SNMP support still needs to be investigated.

Action items: Dave Skeen, who will get a feeling from IBM as to
whether IBM would consider enahancing the tptp ARM agents/infrastructure
as infringing too much on production.

Matt Ming: have a web demo next week of the
existing capablities in BtM in an end to end scenario.

I think it is important that we not miss any existing
functionality in eclipse/tptp, alphaworks, developerworks, etc. There is
probably a lot we can leverage. As we go forward, the BtM effort (me)
should make sure that we get many people's input, even if they are not
part of the team specifically. I am always surprised how talking to
someone "related" to an effort can yield excellent nuggets of what exists.

For now, let's use the Kevin Bacon approach and all please
identify people that should be included and (as appropriate) I will take
the action item to grovel to them for some of their time for their
review. Feel free to invite guest presenters to the Wednesdays BtM
meetings.

Next call, Wednesday at 1PM at the same dial in specificed
elsewhere in the newsgroup. At any time, feel free to email me or get
me on the phone.....
Previous Topic:Meeting Announcement::BTM Use Cases
Next Topic:Revision 0.7 of Project Creation Review Material
Goto Forum:
  


Current Time: Sat Aug 23 11:32:52 EDT 2014

Powered by FUDForum. Page generated in 0.02195 seconds