Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: for the plan.

Jump to: navigation, search


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

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Meeting Title: E4 Resources meeting
Date & Time: Friday Oct 17, 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


  • 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

Old Notes

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

Assigning Work Items

Action Items

Next Meeting

Copyright © Eclipse Foundation, Inc. All Rights Reserved.