Skip to main content
Jump to: navigation, search


< E4‎ | Resources‎ | Meeting
Revision as of 12:25, 19 September 2008 by (Talk | contribs) (New page: {|border=1 cellspacing=0 cellpadding=4 | Meeting Title: | '''E4 Resources meeting''' |- | Date & Time: | Friday Oct 3, 2008 at [

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Meeting Title: E4 Resources meeting
Date & Time: Friday Oct 3, 2008 at 1500 UTC / 11am EST / 8am PST
Ical.gifiCal,Xml.gifATOM News Feed,Html.gifHTML
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

Review of Action Items

Architectural Requirements

  • 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?

Initial Design Ideas

These are just rough ideas. Don't let you scare away. E4 is NOT a big thing driven by some Gurus. It is what we make it. E4 may end up being the current architecture without too much redesign.

  • 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? - Resources are pretty good already, and likely most work items can be implemented in the current architecture. But is it the best choice? Do Resources carry legacy overhead that should be removed? 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:
    • Michael in Last Meeting: Make things simple, avoid complexity. Thinking about Architecture: three layers: (1) EFS; (2) Classic Resources + Mapping by Filtering out stuff (external tools), without overlap, with FS structure; (3) Application Layer, create arbitrary assemblies of Resources like Workingsets or VS projects. We need to make things manageable. Easy to understand and resemble reality.
      • 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?
    • 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.

Assigning Work Items

  • From Last Meeting
  • Any change in meeting schedule / communication channels requested?

Action Items

Next Meeting

Back to the top