archive/working/development/meetingNotes/20050224.txt - gerrit/webtools/webtools.releng - Git at Google

 2/24 meeting

 Attendees:
 David Williams, IBM
 Ted Bashor, BEA
 Chuck Bridgham, IBM
 Naci Dai, Eteration
 Kevin Haaland, IBM

 notes provided by David Williams

 The purpose of this call was to introduce new members, discuss need for
 this group, and is to discuss objectives and our plan for next several months.


 The "formal" statement of our objectives is in our WTP Charter. " The Architecture Group is formed at the
 discretion of the PMC. The Architecture Group is responsible for development, articulation and maintenance of
 the Project Architecture, as well as for providing an explicit description of the architecture and
 communicating this description to all members of the Project, and for releasing it as part of the project
 deliverables. The Architecture Group will accomplish its objectives by working closely with the development
 teams and the PMC. "


 The main work deliverable from the group is an over-all architecture document
 http://www.eclipse.org/webtools/development/arch_and_design/ArchitectureOverview.html


 It was generally agreed there is a need for Architecture Group, to facilitate communication, if nothing else. We
 agreed to have regular phone calls, every other week, the objectives of which would be to

 1.track architecture and design issues and make sure the right people were working on them -- often cross
 component, or even cross project teams, for example, the common browser, the extensible navigator, common
 undo manager. There was a "brainstorm" list of issues . Chuck suggested these be opened as bugzillas, to
 help track. Kevin suggested we as a group prioritize the list, and post a "top ten" list on web to aide
 getting community feedback. [I should add, these would not be the same as "requirements", but obviously
 related.]

 2.We thought it'd be helpful to have some presentations by component leads to Architecture group, to give quick
 overviews of their designs and APIs.

 3. To some extent, our role is to make suggestions and give advice, but a little "police-ing" will undoubtedly be
 part of it  (e.g. "you should have one plugin, instead of 5", etc).


 The following examples were "off the top of David's head" ideas of possible issues to track and focus on.


 1. Two (or three) "command" frameworks in WTP ... which is best? Is the Eclipse base new "command" framework a
 suitable replacement for all of ours?

 2. There's an "EditModel" and "ResourceSet" currently in VE, used by WTP, but rightfully belongs in EMF. I'm
 wondering if the bases new "Logical Resources" substitutes for this?

 3. There's a new Common Undo Manager in base Eclipse ... we in WTP need to see if we can move to this, in place of
 our current common undo manager (that comes from a utility package in EMF). Is there a need for EMF to move too?

 4. Should our WTP Extensible Navigator be promoted to WTP API? Work is slated for Eclipse 3.2 to provide in same
 functionality in base, but will it be the same? Is the timing right?
 Should it be renamed with 'friend' in package (not quite public, but more than internal)? In anticipation of
 changing in 1.1?

 5.  URI Resolver -- how compares with base? How compares with EMF's URI Converter?

 6.  XMLCatalog -- need to confirm its consistent with OASIS specs, XML/DOM3?

 7. Tabbed Property Sheet?  Is there a reason for this to be in base?

 8. Browser framework should be moved to base -- work in progress (but everyone's overloaded).

 9. Internet proxy settings should be moved to base, since effects VM properties (and danger of conflicts if not
 just one provided at a low level).

 10. Validation framework is important and useful, but needs to reconcile with similar function in TPTP, move
 to base in future version?

 11. Do we have or need a consistent logging strategy?

 12. Data collection strategy? (e.g. most frequently used actions, etc).

 13. The flexible project model needs lots of review and feedback.

 14. Need more consolidation of plugins ... some are only used by one or two other plugin, so why not combined?


 The main action for next meeting was for members of Architecture group to exchange "issues lists" and we'd
 pick top ten priorities for release 1 and solicit community feedback.

 Oh, and most important, we agreed to have future meeting as 12 noon Eastern time, instead of 9 AM, except on
 Friday's, so Ted wouldn't have to get up at 6 AM, and Naci could still join in at 7 PM. :)
	2/24 meeting

	Attendees:
	David Williams, IBM
	Ted Bashor, BEA
	Chuck Bridgham, IBM
	Naci Dai, Eteration
	Kevin Haaland, IBM

	notes provided by David Williams

	The purpose of this call was to introduce new members, discuss need for
	this group, and is to discuss objectives and our plan for next several months.


	The "formal" statement of our objectives is in our WTP Charter. " The Architecture Group is formed at the
	discretion of the PMC. The Architecture Group is responsible for development, articulation and maintenance of
	the Project Architecture, as well as for providing an explicit description of the architecture and
	communicating this description to all members of the Project, and for releasing it as part of the project
	deliverables. The Architecture Group will accomplish its objectives by working closely with the development
	teams and the PMC. "


	The main work deliverable from the group is an over-all architecture document
	http://www.eclipse.org/webtools/development/arch_and_design/ArchitectureOverview.html


	It was generally agreed there is a need for Architecture Group, to facilitate communication, if nothing else. We
	agreed to have regular phone calls, every other week, the objectives of which would be to

	1.track architecture and design issues and make sure the right people were working on them -- often cross
	component, or even cross project teams, for example, the common browser, the extensible navigator, common
	undo manager. There was a "brainstorm" list of issues . Chuck suggested these be opened as bugzillas, to
	help track. Kevin suggested we as a group prioritize the list, and post a "top ten" list on web to aide
	getting community feedback. [I should add, these would not be the same as "requirements", but obviously
	related.]

	2.We thought it'd be helpful to have some presentations by component leads to Architecture group, to give quick
	overviews of their designs and APIs.

	3. To some extent, our role is to make suggestions and give advice, but a little "police-ing" will undoubtedly be
	part of it (e.g. "you should have one plugin, instead of 5", etc).


	The following examples were "off the top of David's head" ideas of possible issues to track and focus on.


	1. Two (or three) "command" frameworks in WTP ... which is best? Is the Eclipse base new "command" framework a
	suitable replacement for all of ours?

	2. There's an "EditModel" and "ResourceSet" currently in VE, used by WTP, but rightfully belongs in EMF. I'm
	wondering if the bases new "Logical Resources" substitutes for this?

	3. There's a new Common Undo Manager in base Eclipse ... we in WTP need to see if we can move to this, in place of
	our current common undo manager (that comes from a utility package in EMF). Is there a need for EMF to move too?

	4. Should our WTP Extensible Navigator be promoted to WTP API? Work is slated for Eclipse 3.2 to provide in same
	functionality in base, but will it be the same? Is the timing right?
	Should it be renamed with 'friend' in package (not quite public, but more than internal)? In anticipation of
	changing in 1.1?

	5. URI Resolver -- how compares with base? How compares with EMF's URI Converter?

	6. XMLCatalog -- need to confirm its consistent with OASIS specs, XML/DOM3?

	7. Tabbed Property Sheet? Is there a reason for this to be in base?

	8. Browser framework should be moved to base -- work in progress (but everyone's overloaded).

	9. Internet proxy settings should be moved to base, since effects VM properties (and danger of conflicts if not
	just one provided at a low level).

	10. Validation framework is important and useful, but needs to reconcile with similar function in TPTP, move
	to base in future version?

	11. Do we have or need a consistent logging strategy?

	12. Data collection strategy? (e.g. most frequently used actions, etc).

	13. The flexible project model needs lots of review and feedback.

	14. Need more consolidation of plugins ... some are only used by one or two other plugin, so why not combined?


	The main action for next meeting was for members of Architecture group to exchange "issues lists" and we'd
	pick top ten priorities for release 1 and solicit community feedback.

	Oh, and most important, we agreed to have future meeting as 12 noon Eastern time, instead of 9 AM, except on
	Friday's, so Ted wouldn't have to get up at 6 AM, and Naci could still join in at 7 PM. :)