Skip to main content
Jump to: navigation, search

Difference between revisions of "E4/Resources/Meeting/17-Oct-2008"

< E4‎ | Resources‎ | Meeting
(New page: {|border=1 cellspacing=0 cellpadding=4 | Meeting Title: | '''E4 Resources meeting''' |- | Date & Time: | Friday Oct 17, 2008 at [http://www.timeanddate.com/worldclock/fixedtime.html?m...)
 
 
(8 intermediate revisions by 4 users not shown)
Line 34: Line 34:
 
* Last Meeting: [[E4/Resources/Meeting/3-Oct-2008]]
 
* Last Meeting: [[E4/Resources/Meeting/3-Oct-2008]]
 
** [[Image:Ok_green.gif]] '''Martin:''' [[E4/Resources/Definitions of Terms]]
 
** [[Image:Ok_green.gif]] '''Martin:''' [[E4/Resources/Definitions of Terms]]
** '''DougS''' to advertise moving discussion onto the E4 mailing list
+
** [[Image:Ok_green.gif]] '''DougS''' to advertise moving discussion onto the E4 mailing list
 
** '''DougS''' to create a Strawman API to look at  
 
** '''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 [https://bugs.eclipse.org/bugs/show_bug.cgi?id=249745#c10 Bazaar], Mercurial, Git if we want to do much branching / parallel work
  
 
=== Architecture ===
 
=== Architecture ===
Line 41: Line 47:
 
** [[E4/Resources/Filesystem]]
 
** [[E4/Resources/Filesystem]]
 
*** '''Consensus:''' Add FS-based alias support, notifications, asynchronous APIs
 
*** '''Consensus:''' Add FS-based alias support, notifications, asynchronous APIs
*** '''Tentative:''' Add Meta-info / Marker support (separate layer?) , FS-based content type / encoding support
+
*** '''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 [http://openjdk.java.net/projects/nio/ Java7 / JSR203] and made a [http://dev.eclipse.org/mhonarc/lists/eclipse-incubator-e4-dev/msg00852.html proposal] on the mailing list for adding EFS API
 
*** '''To Discuss:''' Add IResource#getFileStore(), or keep them linked via URI only?
 
*** '''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?
 
**** Is the FS layer stateless, or do we need some notion of Caching?
 +
**** Scott proposed [[ECF_API_Docs | 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 [http://wiki.apache.org/hadoop/DFS Hadoop DFS] for example of doing replication/caching for distributed file systems.
 
** Project Layer (classical Resources)
 
** Project Layer (classical Resources)
*** '''Consensus:'''  
+
*** '''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 [http://dev.eclipse.org/mhonarc/lists/eclipse-incubator-e4-dev/msg00776.html 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
 
** Application Layer
 +
*** Improved Working Sets?
 +
*** Resource Views / Perspectives with filtered notifications?
 +
*** Pluggable Project Persistence?
 +
*** Sharing/Linking/Inheritance of project settings?
  
 
=== Old Notes ===
 
=== Old Notes ===
Line 70: Line 88:
 
=== Assigning Work Items ===
 
=== Assigning Work Items ===
 
* Interested Parties from [[E4/Resources/Meeting/19-Sep-2008 Kick-off#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: [http://bugs.eclipse.org/84988 bug 84988].
  
 
== Action Items ==
 
== 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 Meeting ==
 
* Next [[E4/Resources/Meeting/31-Oct-2008]] (2 weeks after)
 
* Next [[E4/Resources/Meeting/31-Oct-2008]] (2 weeks after)

Latest revision as of 13:03, 17 October 2008

Meeting Title: E4 Resources meeting
Date & Time: Friday Oct 17, 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 #

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

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?)
      • 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

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

Back to the top