E4/Resources/Meeting/17-Oct-2008
Meeting Title: | E4 Resources meeting |
Date & Time: | Friday Oct 17, 2008 at 1500 UTC / 11am EST / 8am PST![]() ![]() ![]() |
Canada and US Toll Free: | (866) 740-7083 |
International Dial-in: | +1 (702) 696-4217 (more numbers here) |
Conference ID: | 613 277 0037 # |
Contents
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?
- Consensus: Need physically nested projects bug 245412. May be tricky related to alias management.
- Application Layer
- Improved Working Sets?
- Resource Views / Perspectives with filtered notifications?
- Pluggable Project Persistence?
- Sharing/Linking/Inheritance of project settings?
- E4/Resources/Filesystem
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)