Jump to: navigation, search

E4/Resources/Meeting/3-Oct-2008

< E4‎ | Resources‎ | Meeting
Revision as of 08:27, 13 October 2008 by Martin.oberhuber.windriver.com (Talk | contribs)

(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 #

Attendees

  • Wind River - Doug Schaefer, Martin Oberhuber
  • Google - Terry Parker
  • IBM - Chris Rekoskie, Kevin McGuire, Mike Wilson, Szymon Brandys, John Arthorne
  • nVidia - Eric Frey
  • Embarcadero - Kenn Hussey
  • Broadcom - James Blackburn
  • Ed Merks

Notes

Administrative

  • Move discussions to e4-dev list only, tagged with [resources] AI Doug send the message out
  • E4 now a subproject of the toplevel Eclipse project, going to set up a Repository.
    • No separation of commit rights - everybody can commit everywhere - but probably going to have multiple Repositories

Strawman Proposal

Filesystem Layer

  • IBM/McQ - Szymon wants to be able to deal with System/i or System/z file systems: could have 2 aliases for the same directory, but depending on the path going there, one could be case sensitive, the other not
  • Add symbolic link awareness
  • Making the file system layer more powerful, writing providers becomes more difficult. Might want to have superclasses with default implementations for some commonly needed functionality
  • Asynchronous APIs
  • Other file system APIs
    • Apache Commons VFS (similar to EFS, but weak specific implementations);
    • KDE / KIO looked neat (has both synchronous and async variants, that's interesting)
  • McQ: Might want a "pass-thru" layer between Resource and FS layer
  • ChrisR: Want to deal with files that live outside the Resource tree -- may want to express stateful things (such as caching) to such files as well
  • Some Metadata (Markers) should live on the filesystem layer
  • On what items are editors opened on: IResources or Files? Likely Files...
  • Martin: What is the borderline between Resources and Files? Pushing down a lot of functionality into the file system.
    • File system always is an accurate view of the world, not backed by an in-memory tree.
    • Resource deltas at project level only. For direct manipulations on the file system, invent some additional notification mechanism (between project and FS) - perhaps similar to RefreshMonitor. Deltas need to know the state before the change happened.
    • Filtering: projects to explicitly turn files into resources ("yes, I want notifications for those")
  • McQ: We need somebody to actually stand up and implement it - and its APIs - Consensus:
    • Want both synchronous and asynchronous APIs
      • Comment from slewis: Please consider ECF filetransfer API (or some extension) for asynchronous file transfer. Already being used by p2 for asynch file transfer. Can/could be extended.
    • Probably want Metadata on a separate layer
  • Martin want somebody to own the process of Requirements Gathering for the FS Layer
    • Doug wants to see API Proposals to add onto EFS
  • Don't add too much to it, since every implementation needs to implement it. Having multiple layers takes burden off the implementers.
  • McQ: Currently, Resources are the Metadata layer. Are there fundamental issues which preclude keeping the resource layer for metadata?
    • On the UI group, it worked fine having some people with a very clear vision just walk off and draft some API

Project Layer

  • Have some resources not map to any file at all
  • Backward compatibility: deprecate IResource#getLocation()?
    • Martin: start deprecating things now
    • McQ: Deprecating things is ok, but actually pulling them out would be a mistake (need a compatibility layer)
    • Introduce new APIs for the "native E4" way of working with a compatibility layer for the old way

Action Items

  • DougS to advertise moving discussion onto the E4 mailing list
  • DougS to create a Strawman API to look at
  • Continue ML discussions, start picking up work items. Items without ownership will be dropped.

Next Meeting