Skip to main content
Jump to: navigation, search

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

< E4‎ | Resources‎ | Meeting
(Review of Action Items)
(Notes)
 
(3 intermediate revisions by 2 users not shown)
Line 16: Line 16:
 
|}
 
|}
  
== Invited Attendees ==
+
== Attendees ==
* Wind River - Doug Schaefer, Michael Scharf, Martin Oberhuber
+
* Wind River - Doug Schaefer, Martin Oberhuber
* Google - Terry Parker, Tom Ball, Sergey Prigogin
+
* Google - Terry Parker
* Freescale - Serge Beauchamp
+
* IBM - Chris Rekoskie, Kevin McGuire, Mike Wilson, Szymon Brandys, John Arthorne
* IBM - Boris Bokowski, Mike Wilson, Szymon Brandys, Chris Recoskie, John Arthorne
+
* nVidia - Eric Frey
* Nokia - Ken Ryall
+
* NVidia - Eric Frey
+
 
* Embarcadero - Kenn Hussey
 
* Embarcadero - Kenn Hussey
 
* Broadcom - James Blackburn
 
* Broadcom - James Blackburn
 +
* Ed Merks
  
* '''Call is Open, Anybody else can join, also users and non-committers -- list above is just the people from the last meeting.'''
+
== Notes ==
 +
* Previous [[E4/Resources/Meeting/19-Sep-2008 Kick-off]]
  
== Agenda/Notes ==
+
=== Administrative ===
'''Feel free to edit, but <font color="red">not during the meeting</font>'''
+
* 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
  
=== Review of Action Items ===
+
=== Strawman Proposal ===
* Last Meeting: [[E4/Resources/Meeting/19-Sep-2008 Kick-off#Action Items]]
+
* [[E4/Resources/Strawman]]
** [[Image:Ok_green.gif]] '''Martin:''' [[E4/Resources/Definitions of Terms]]
+
==== 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_API_Docs#File_Transfer_API | 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
  
=== Architectural Requirements ===
+
==== Project Layer ====
* From [[E4/Resources/Requirements]]:
+
* Have some resources not map to any file at all
* Must not break fundamental expectations of existing clients.
+
* Backward compatibility: deprecate IResource#getLocation()?
** ''What are hard client expectations in terms of project structure?''
+
** Martin: start deprecating things now
** What about other expectations?
+
** 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
=== Initial Design Ideas ===
+
<font color="green">'''These are just rough ideas. Don't let you scare away. E4 is NOT a big thing driven by some Gurus. It is what we make it. E4 may end up being the current architecture without too much redesign.'''</font>
+
 
+
* ''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?''' - Resources are pretty good already, and likely most work items can be implemented in the current architecture. But is it the best choice? Do Resources carry legacy overhead that should be removed? 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:'''
+
** '''Michael''' in [[E4/Resources/Meeting/19-Sep-2008 Kick-off|Last Meeting]]: Make things simple, avoid complexity. Thinking about Architecture: three layers: (1) EFS; (2) Classic Resources + Mapping by Filtering out stuff (external tools), without overlap, with FS structure; (3) Application Layer, create arbitrary assemblies of Resources like Workingsets or VS projects. '''We need to make things manageable'''. Easy to understand and resemble reality.
+
*** 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?
+
** 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 ===
+
* From [[E4/Resources/Meeting/19-Sep-2008 Kick-off#Work Items|Last Meeting]]
+
* Any change in meeting schedule / communication channels requested?
+
  
 
== Action Items ==
 
== 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 Meeting ==
 
* Next [[E4/Resources/Meeting/17-Oct-2008]] (2 weeks after)
 
* Next [[E4/Resources/Meeting/17-Oct-2008]] (2 weeks after)

Latest revision as of 07:27, 13 October 2008

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

Back to the top