Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: for the plan.

Jump to: navigation, search


< E4‎ | Resources‎ | Meeting
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


  • How and where to start prototyping?
    • Much work currently ongoing in 3.x Stream
    • e4 CVS Repository not yet ready
    • Consider Bazaar, Mercurial, Git if we want to do much branching / parallel work


  • 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, asynchronous APIs (I/O only but not for directory retrieval?)
      • 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?
        • Scott proposed ECF filetransfer API for asynchronous file tranfser API. It's there, it works, it has a simple-but-extensible API and it's part of Equinox already.
        • Scott sent note about Hadoop DFS for example of doing replication/caching for distributed file systems.
    • Project Layer (classical Resources)
      • Consensus: Need physically nested projects bug 245412. May be tricky related to alias management.
        • bug 229633 linked resources with relative path / variable-based (Serge Beauchamp)
        • Alias Management for symlinks - Martin working on bug 233939, using IFileStore#getCanonicalPath()
        • Who's going to take on Resource Tree Filters?
      • Tentative:
        • Lazy Resources as proposed by Martin on the mailing list: instead of pushing down IResource stuff into the file system, allow resources to work more "lazily" without eager refresh, such that they can be used for stuff outside the Workspace - is this a viable idea?
    • Application Layer
      • Improved Working Sets?
      • Resource Views / Perspectives with filtered notifications?
      • Pluggable Project Persistence?
      • Sharing/Linking/Inheritance of project settings?

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


  • Get a list of open bugs on resources
    • Add new bugs
    • Available to back port
  • Remote file systems
    • Agents to do work remotely
    • How do we know operations are going to be slow
    • Deal with slow operations in the UI
    • Need to be able to cancel
    • Make progress monitors more prevalent
    • Throw core exceptions on failures
    • Common caching schemes
      • Cache validation, number of different schemes
    • ReST - Representation State Transfer
    • Separate out deltas as a separate service (batch change mechanism)
    • Can we make IResource more lightweight so it can deal with 100,000 files.
    • Existing bug on filtering: bug 84988.

Action Items

  • If you have an idea that you can code up to help us understand, please do so and attach to a bug.
  • On the list, let's talk a bit more about the delta mechanism and the IResource layer.

Next Meeting

Back to the top