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.

Agenda/Notes

Feel free to edit, but not during the meeting

Review of Action Items

• 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

Provisioning

• 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

Architecture

• 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?)
      • Martin looked at Java7 / JSR203 and made a proposal on the mailing list for adding EFS API
    • 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

• Interested Parties from E4/Resources/Meeting/19-Sep-2008 Kick-off#Work Items

Minutes

• 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

• Next E4/Resources/Meeting/31-Oct-2008 (2 weeks after)