E4/Resources/Meeting/3-Oct-2008
| Meeting Title: | E4 Resources meeting |
| Date & Time: | Friday Oct 3, 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 # |
Contents
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
- Want both synchronous and asynchronous APIs
- 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
- Next E4/Resources/Meeting/17-Oct-2008 (2 weeks after)