Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
|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 #|
- 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
- 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
- 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:
- 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.
- 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?
- 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
- 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
- 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.
- 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 E4/Resources/Meeting/31-Oct-2008 (2 weeks after)