E4/Resources/Meeting/17-Oct-2008

Meeting Title:	E4 Resources meeting
Date & Time:	Friday Oct 17, 2008 at 1500 UTC / 11am EST / 8am PST iCal,ATOM News Feed,HTML
Canada and US Toll Free:	(866) 740-7083
International Dial-in:	+1 (702) 696-4217 (more numbers here)
Conference ID:	613 277 0037 #

Invited Attendees

Wind River - Doug Schaefer, Michael Scharf, Martin Oberhuber
Google - Terry Parker, Tom Ball, Sergey Prigogin
Freescale - Serge Beauchamp
IBM - Boris Bokowski, Mike Wilson, Szymon Brandys, Chris Recoskie, John Arthorne
Nokia - Ken Ryall
NVidia - Eric Frey
Embarcadero - Kenn Hussey
Broadcom - James Blackburn

Call is Open, Anybody else can join, also users and non-committers -- list above is just the people from the last meeting.

Feel free to edit, but not during the meeting

Last Meeting: E4/Resources/Meeting/3-Oct-2008
- Martin: E4/Resources/Definitions of Terms
- DougS to advertise moving discussion onto the E4 mailing list
- DougS to create a Strawman API to look at

Layered Architecture:
- E4/Resources/Filesystem
  - Consensus: Add FS-based alias support, notifications, asynchronous APIs
  - Tentative: Add Meta-info / Marker support (separate layer?) , FS-based content type / encoding support
  - To Discuss: Add IResource#getFileStore(), or keep them linked via URI only?
    - Is the FS layer stateless, or do we need some notion of Caching?
- Project Layer (classical Resources)
  - Consensus:
- Application Layer

From E4/Resources/Requirements:
Must not break fundamental expectations of existing clients.
- What are hard client expectations in terms of project structure?
- What about other expectations?

Jeff McAffer: Keep simple things simple. Make hard things possible. Strive for Separation of Concerns. - Architecture Council/Top Ten Recommendations
Ward Cunningham: What is the simplest solution that could possible work?
Incremental Changes or Redesign? - What about architectural issues such as bug 181998 Resources Plugin performs too much work in Activator.start()?
- Asynchronous APIs can always be driven by a synchronous facade, but not the other way round

Layering:
- Martin: The simplest set of rules is: There's a file system abstraction, a generic mechanism for metadata on resources, a pluggable persistence mechanism, client-defined views/perspectives on resources, change notifications and atomic operations. Pushing down application-layer filters could allow for more concurrency, fewer event firing, less memory (due to filtering).

- Alias Management - a layer of its own, or fundamental intrinsic part of Resources (File System)?
- Improved (pluggable) Metadata on Resources - a Layer of its own? Anybody interested at all?

Martin: Make Resources Simpler. Resources today are likely doing too much. Consider splitting up in separate layers for filesystem abstraction (EFS++ asynchronous), then Alias Management, then caching/refresh/delta notifications/operations, then meta-info and logical structure, then model-based views. Builders could be special clients/operations/meta-info on top of the generic architecture and be used or not at an RCP's disposal. A new asynchronous base model with adaption layers to the old APIs if needed.