blob: 1bd2631a9454aaa8d41d755822fd766328f9b12b [file] [log] [blame]
david_williamsd0553f72005-03-14 18:52:26 +000013/10 meeting
4David Williams, IBM
5Ted Bashor, BEA
6Chuck Bridgham, IBM
7Naci Dai, Eteration
8Kevin Haaland, IBM
10notes provided by David Williams
12On the issue of "provisional APIs" .... I'll document here the position the WTP Architecture Group which discussed
13this issue in last meeting. Initially, we were unanimously agreed anything that's not API should not be identified
14as "proposed API" via package names but instead through other forms of JavaDoc and "proposal documents" for
15"future releases". But, as we continued to discuss areas we would (likely) recommend that not be API in release 1,
16it became apparent there could easily be some cases where it might improve review and feedback for iterative
17design -- so, we would not object to "internal.provisional" in package names as long as 1) the correct expectation
18is set that there is no guarantee of future compatibility (possibly not even in maintenance stream/fixes), so
19clients have to be prepared to respond, if they use it, as they would any other "internal" use, and 2) the use of
20"internal.provisional" should not be used lightly ... component leads would be expected to have some degree
21justification for using it (such as the best justification would be: "known clients willing to use 'internal'
22classes, desired future API function, but planned to be moving to a different project next release" or similar).
23As Arthur said, its use it optional, and there are other ways of "giving hints" as to future proposed API
26I think this is all consistent with the sum total of previous comments posted to wtp-dev (its meant to be), and
27I'm just trying to publically document Architecture Groups concerns and discussion of it.
30= = = = = = = =
32Architecture and Design Issues the Architecture Group is proposing as some of the most important to resolve for
33Release 1. I'll open bugzilla "issues" for the most important of these, marked with [arch] in summary to help
34track and soliciti community feedback.
361. making sure API commitments are solid, platform quality. .
37Components leads need to provide easy to find, "central place" for reading about their design overviews, proposed
38APIs, etc., including a description and justification for their plugin structure (its felt there's probably still
39too many separate plugins, but we are not sure of what reasons are). We'll schedule brief "reviews" with component
40leads, but the "live" review will by necessity need to be brief, so still expect most of work done prior to Arch.
41group's review and much of work done by community and clients of the API.
42To be Scheduled soon.
452. Flexible project model
46Such a "large change" to the traditional "Eclipse Way" of doing projects may be hard to "get right" the first
47time. That is, needs lots of review and iteration and "client use".
48Especially there may be release 2 issues with base Eclipse, that is, if base Eclipse provides "more support" in
49release 3.2, would all our flexible project API still be correct?
50should it be API in Release 1 of WTP or a "provisional API"?
51Chuck and Naci to review status/recommendations with Architecture Group on or near 4/21.
52Ted to provide interested party from BEA.
553. Server APIs
56is it adequate? Getting correct "add on" feedback?
57Ted will propose "publish" participation, similar to "deploy" participation
58Do we need scheduled review? Or, just have people open their bugzilla's if see issues?
59(I'll pick the later for now, since this component has gotten lots of review).
614. Operation (command) Framework.
62Two (or three) "command" and/or "operation" frameworks in WTP ... which is best? Is the Eclipse base new
63"operation" framework (not to be confused with Command framework) a suitable replacement for all of ours?
65Chris Brealey
66Chuck Bridgham
67see and post to mailing list
68[Michael Van Meekeren and Doug Polick interested parties from base Eclipse]
69Ted Bashor interested from BEA
71Kevin says platform's goal is to provide the one-and-only operation framework ....
72so, no API in WTP!? We in WTP may not want to move in 3.1, but should he recommends WTP at least
73review base support by 3.1, and move to that in 3.2 and not introduce competing API
74Chuck is not sure what he and Chris call "command/operation/wizard" frameworks are related to "Operations
75framework" in base.
76Suggest Chris/Chuck to report/review with Architecture Group on or before 4/21.
77Sounds unlikely to be API in WTP 1.0.
795. EditModel.
80There's an "EditModel" and "ResourceSet" (EMF) currently in VE, used by WTP, but rightfully belongs in EMF. I'm
81wondering if the bases new "Logical Resources" substitutes for this or if we just need to work on getting in EMF?
82Chuck reports similar but "more than" logical resources ... so he'll work with Ed to "beef up" EMF resource Set to
83EditModel Chuck Bridgham to work with Ed Merks likely NOT to be WTP API (but maybe EMF API) Chuck to report/review
84on or before 4/21
866. Common Undo. There's a new Common Undo Manager in base Eclipse ... we in WTP need to see if we can move to
87this, in place of
88our current common undo manager (that comes from a utility package in EMF). Is there a need for EMF to move too?
89(Common, btw, means
90one per resource or resource set, not just one implementation. The base Eclipse has, basically, one per editor,
91plus new work going on).
93Nitin Dahyabhai
94EMF - Ed Merks
95Would it help if Ed can move his command stack "utility" to common framework, so no changes needed in WTP this
97Suggest Nitin to report/review on or before 4/21
997. Extensible Navigator. Should our WTP Extensible Navigator be promoted to WTP API? Work is slated for Eclipse
1003.2 to provide in similar functionality in base Eclipse, but will it be the same? Sufficient? Should it be
101internal in anticipation of changing in 1.1?
103Michael Elder
104Michael Van Meekeren
105Mr. Elder to present/review with Arch. Team by 4/7
106likely NOT API in WTP, but Ted (BEA) concerned about that since they will likely have to use in client
107(That is, they can probably manage risk of "using internal" but want to be sure its clear what is proposed for
108future API so their use of internal is at least in right direction and they can provide valid feedback).
1118. Tabbed Property Sheet? Is there a reason for this to be in base (its not strictly a "web function", though
112required by WTP)? Reason to be WTP API?
113Craig to report/review on 3/24
114Probably not API, should probably move to base, but need time, need clear statement of intent.
115Craig to send documentation pointers to Kevin (and CC Arch. group) and Kevin will see if someone from base can at
116least review for suitability.
1199. URI Resolver -- how compares with base resolving schemes? How compares with EMF's URI Converter?
122Craig Salter
123Nitin Dahyabhai
124BEA - Gary Horton (interest in future "schema paths" similar to "class paths").
125Suggest Craig to report/review on 4/7.
12710. XMLCatalog -- need to confirm its consistent with OASIS specs, XML/DOM3?
130Craig Salter
131BEA - ... Ted to get back with a name of interested parties in BEA.
132Suggest Craig to report/review on 4/7
13411. Browser framework should be moved to base -- work in progress (but everyone's overloaded).
135Tim DeBoer
136Dejan Glozic
137Suggest Tim to report/review on 3/24
14012. Internet proxy settings should be moved to base, since effects VM properties (and danger of conflicts if not
141just one provided at a low level).
142Chris Brealey
143have Chris contact Kevin with documentation pointers (and CC Arch. group), he'll see if can be made part of
144"update" component,
145or, at minimum, reviewed by base team for 3.2 item.
146Suggest Chris to report/review on 4/7
149= = = = =
150Following are already thought to be "future release" issues
15313. Validation framework is important and useful, but needs to reconcile with similar function in TPTP, move
154to base in future version? (initial indication indicates not move to base, at least anytime soon).
155I suggest we make this a "future release" item, but put team in place now to be sure requirements, basic API is
157Interested Parties:
david_williams66ffa5c2005-04-06 15:53:19 +0000158David Williams (IBM, WTP/SSE)
159Ted Bashor (BEA, WTP)
160Vijay Bhadriraju (IBM, WTP/J2EE)
161Alex Iskold (IBM, TPTP)
david_williamsd0553f72005-03-14 18:52:26 +0000162DW to report/review on 6/2
16514. Do we have or need a consistent logging strategy? Doesn't need our attention now, but maybe next release.
166Kevin recommends we (WTP) see and comment on bug 83550.
16815. Ted mentioned need for "crash/bug reporting" back to central (or predesignated) spot. I think some of this is
169in TPTP, but not sure how accessible. See/comment on bug 83550. Definitely a "base provided function" ... only
170question for WTP is if its transparent, or some degree of support we'd have to build in.
17216. Data collection strategy? (e.g. most frequently used actions, preferences changed, etc). More of a future
173concern, but may be able to use base support transparently using instrumentation plugin Eclipse Foundation is
174looking at "how to" do (signed jars to protect receipt of data, receiving feedback at central site, etc).