| Agenda/Notes for 4/21 meeting |
| |
| Invitees: David, Kevin, Naci, Ted, Chuck |
| Special Guests: Chris Brealey |
| |
| Attendees |
| 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 cbridgha@us.ibm.com david_williams@us.ibm.com [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 mdelder@us.ibm.com david_williams@us.ibm.com [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. |
| |
