blob: 09d103821a251c76745c600808ef6f36d460a254 [file] [log] [blame]
Agenda/Notes for 4/21 meeting
Invitees: David, Kevin, Naci, Ted, Chuck
Special Guests: Chris Brealey
Invitees: David, Chuck
Special Guests: Chris Brealey
(Naci had warned might not make it, Ted confirmed, but
didn't call, and Kevin probably lost in Release 3.1 :)
1. Progress on Arch. Doc. for M4?
Chuck? Ted?
no progress, but still planning to do "by end of next week".
(please allow time for iteration)
2. Operations in WTP
See 88009 maj P3 [arch] Should WTP "operations" be API?
I'd like Chuck to explain if/how they are extending base operations .... and if sounds right to Kevin.
I'd like Chris to discuss how/why his "command" API is "internal.provisional",
instead of just 'internal' .. since we want
to end up with "one and only one operations API".
complete resolution/integration deferred to WTP 1.1
DataModels/Operations, very small API (believed in synch with base spec,
believed evolvable, needs good review to verify)
Fundamental problem/question/issue of "execution environment"
-- should/can WTP provide API that's intended to run
outside of Eclipse Environment? Or, can an
"Eclipse headless" application be made small enough
and fast enough to be transparent (new "jarred plugins"
might help)?
3. Flexible Project status:
Some technical details are being tracked in
91708 nor P3 [arch] Flexible projects need to coordinated SchedulingRules
But, I think more important issues are:
A. Does part of flexible project API belong in base Eclipse .... and if so, does it
make sense for us to still declare as API, and then migrate in 3.2?
(Ted raised some issues after last meeting, in an email, so maybe he could lead this discussion)
B. Since the team that is defining the API is the primary (only?) consumer of the API ..
is this reason to hold off proposing it as final API ... make it provisional instead?
Are others lined up to review/use?
SchedulingRules approach seems feasible, still need to think through
how to spec to clients for them to "get" the right scheduling rules
(for example, might need to "bubble up" to EditModel API too).
Need more work to document well what *users* of flexible projects use,
versus *providers* of flexible projects need to do. Some chance the
former might be "ready for API", but the later not.