Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "E4/Resources/Meeting/19-Sep-2008 Kick-off"

< E4‎ | Resources‎ | Meeting
(Work Areas)
 
(9 intermediate revisions by 2 users not shown)
Line 18: Line 18:
 
== Attendees ==
 
== Attendees ==
 
* Wind River - Doug Schaefer, Michael Scharf, Martin Oberhuber
 
* Wind River - Doug Schaefer, Michael Scharf, Martin Oberhuber
* IBM - John Arthorne, Szymon Brandys, Chris Recoskie
+
* Google - Terry Parker, Tom Ball, Sergey Prigogin
* Competitrack - Yma
+
* Embarcadero - Kenn Hussey
+
 
* Freescale - Serge Beauchamp
 
* Freescale - Serge Beauchamp
* Intel - Sergey Prigogin
+
* IBM - Boris Bokowski, Mike Wilson, Szymon Brandys, Chris Recoskie, John Arthorne
 
* Nokia - Ken Ryall
 
* Nokia - Ken Ryall
 
* NVidia - Eric Frey
 
* NVidia - Eric Frey
 +
* Embarcadero - Kenn Hussey
 +
* '''Regrets:''' Broadcom - James Blackburn
  
 
== Agenda ==
 
== Agenda ==
Line 33: Line 33:
 
== Notes ==
 
== Notes ==
 
=== Interested Parties and Background ===
 
=== Interested Parties and Background ===
* [[E4/Resources/Requirements, Use-Cases and Goals]]
+
* '''Doug Schaefer''': Wanted to enable VS projects in Eclipse, that initial work later carried on by Ken Ryall (Nokia). Idea was a virtual file system similar to EFS. Ran into troubles due to assumptions of clients (external tools) that resources are backed by a physical file system. EclipseCon 2008 discussion picked up by E4 effort.
 +
** McQ: For making Eclipse more pervasive, E4 gives us the freedom to take a step back without immediate need for backward compatibility
 +
* '''Serge Beauchamp''': Metroworks CodeWarrior background (similar to VS). Need flexible project structure {{bug|229633}}.
 +
** Martin: It's not decided yet whether E4 will be a vast, big effort -- it will be what we as a community make it. For now, just all items are on the table. All input is valuable!
 +
* '''Ken Ryall''': Many customers coming from CodeWarrior having file-list based project structure. Want migration into Eclipse. Interested in working on broader changes, did some work on flexible file system prototype in CDT (virtual file system), encouraged by initial results. Interested in 3.5 shorter-term fixes. Customers want standard, unmodified Platform. Scalability and filtering (very large projects)
 +
* '''Terry Parker & Tom Ball''': Very large code bases on Linux, current model falls down in some cases:
 +
** '''Complete refresh''' of the workspace don't work - HIDDEN attribute doesn't keep resources from being traversed. Want to exclude portions of large underlying file system. IntelliJ can pull the entire codebase in (Eclipse is killed by that)
 +
** '''Aliased paths''' (symbolic links) - canonical form of paths (better comparator) instead of plain Strings
 +
** '''Sergey Prigogin''': Hiding stuff must be done before EFS, before Resource creation
 +
* '''Ken Hussey''': Make Resources file system agnostic, more RESTful style of resources. Better Content Types instead of file extensions. Filtering ("what's visible" based on resource sets)
 +
** Chris, Doug - For external tools and version control, EFS mapping to physical paths is a problem
 +
* '''Chris Recoskie''': Import existing physical project structures into CDT; Remote Resources;
 +
* '''Martin Oberhuber''': Bringing large legacy file structures into Eclipse, making it easier for customers to apply Eclipse to their daily work. Physical project nesting, Flexible Projects. Also interested in Architecture but with lower priority.
 +
* '''Michael Scharf''': 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.
 +
** DougS: Clearcase remote client has a good workflow. Resource system as a View on something.
 +
** '''John Arthorne''': Could be several different application layers. One characteristic of EFS is that it's stateless, whereas one big value-add of the Resource model is that it's adding state (markers, sync info, ...) on top of physical.
 +
** DougS: How to attach metadata that gets checked in? (Coming from the Build angle)
 +
** Have different types of notifications (on resource layer and application layer)
 +
** Boris: Currently, notifications are on workspace basis. Might want multiple workspaces.
 +
** Martin: Multi-workspace also interesting to work on multiple versions of same project (name resolution)
 +
** McQ: Name resolution inside single workspace would also be interesting.
 +
** McQ: Using EFS for arbitrary filesystem-like things is pushing it too far. On a remote workspace, it's likely that Build wouldnever have to occur locally. Distributed is interesting, but don't warp this into EFS.
 +
* '''McQ''': Want to give insight in why things are the way they are, but won't be able to invest lots of resources.
 +
* '''Boris Bokowski''': Interested in architectural side of things, want to get rid of Singletons
 +
* '''Szymon Brandys''':
 +
* '''Eric Frey''': Large user of Eclipse, writing individual tools, want to be Ecilpse based. Need flexible resource and project model (projects in same directory) - based on VS
 +
** Michael: need to think about what a project is (root dir + meta info) - that's different than the definition of project in other IDE's
 +
** Doug: Lots of problems in the past in CDT came from trying to apply Eclipse concepts to non-Eclipse worlds -- e.g. Autobuilder. In reality, CDT build does work differently. Looking at modeling stuff in the resource system that can help.
 +
** McQ: One of the big differentiators of Eclipse to other IDEs is Autobuild, the power of Resource Deltas. This needs to be part of the solution.
 +
** Doug: Have 2 builders in CDT, one of them based on resource deltas but most people work on external make (''which is annoying''). Doug wants to fix the architecture such that external builders work better.
 +
* McQ: What about '''Logical Model Support''' that's in place now? Managing sub-file or super-file resources? - Resources can be adapted to ResourceMapping, which describes related resources. Allows writing all of them to repository in one operation.
 +
** Michael: We need to come up with a common terminology and need to agree on a meaning.
 +
* Doug: Wants to start talking in terms of work items, and stuff that we want to start prototyping right away. Want more discussion on platform-core-dev mailing list.
 +
** Where should prototyping happen?
 +
** Boris: Will get the project created soon.
 +
 
 +
=== Galileo vs E4 ===
 +
* Adding stuff to Galileo already is compelling, but what about the Risk of creating new complications in terms of compatibility for the "Real solution"?
 +
** McQ is a big fan of adding features early, if it doesn't conflict with the big picture.
 +
** Most participants will want part features implemented early.
  
 
=== Work Areas ===
 
=== Work Areas ===
 
* [[E4/Resources/Work Areas]] - the big rocks:
 
* [[E4/Resources/Work Areas]] - the big rocks:
** Improved '''Alias Management''' - Fix issues with symbolic links / linked resources - multiple nodes pointing to the same content - clarify semantics of aliasing / overlapping
+
** '''Improved [[E4/Resources/Work_Areas#Alias_Management|Alias Management]]''' - Fix issues with symbolic links / linked resources - multiple nodes pointing to the same content - clarify semantics of aliasing / overlapping
*** ''A layer of its own that can be added/removed?''
+
*** ''Alias Management'': Terry, Sergey (Google), James (Broadcom), Martin (Wind River)
** Improved '''Project Structure''' - relative/variable-based linked resources, file-list-based projects, multi-workspace, physical/logical project nesting, namespace resolution, perspectives/filtering
+
** '''Improved [[E4/Resources/Work_Areas#Workspace_and_Project_Structure|Project Structure]]''' - relative/variable-based linked resources, file-list-based projects, multi-workspace, physical/logical project nesting, namespace resolution, perspectives/filtering
*** ''What are hard client expectations in terms of project structure?''
+
*** ''Filtering'': Sergey, Terry, Tom (Google), Ken (Nokia), Kenn (Embarcadero), Martin, Michael (Wind River)
** Improved '''Meta Data''' - More settings levelling, arbitrary metadata attached to resources with persistence or from file system (with lifecycle ala markers), pluggable project/metadata persistence (interoperability with other IDEs)
+
*** ''Refresh/Large Workspace Performance'': Terry, Tom (Google), Ken (Nokia)
*** ''Another pluggable layer?''
+
*** ''Flexible Project Structure'': Doug (Wind River), Serge (Freescale), Ken (Nokia), Chris (IBM), Eric (NVidia), James (Broadcom)
** Improved '''Remote Support''' - improved handling of latency, errors, caching; support for remote workspaces; physical/logical path translation
+
*** ''Physical Project Nesting'': Martin (Wind River)
** Improved '''Programming Model''' - more concurrency, more componentization, fewer listeners, listener order and race conditions, no Singletons (See also [[E4/Pervasive Themes]]
+
*** ''Multiple Workspaces'': Boris, McQ (IBM), Martin (Wind River)
 
+
*** ''Namespace resolution'': McQ (IBM)
=== Some random architectural ideas ===
+
*** ''Multiple Projects in one Dir'' - Eric (NVidia)
* ''Jeff McAffer: Keep simple things simple. Make hard things possible. Strive for Separation of Concerns.'' - [[Architecture Council/Top Ten Recommendations]]
+
** '''Improved [[E4/Resources/Work_Areas#Improved_Metadata_and_Persistence|Meta Data]]''' - More settings levelling, arbitrary metadata attached to resources with persistence or from file system (with lifecycle ala markers), pluggable project/metadata persistence (interoperability with other IDEs)
* ''Ward Cunningham: What is the simplest solution that could possible work?''
+
*** ''Arbitrary Persistable Data on Resources'' - Doug (Wind River), for Builders
* '''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()?
+
** '''Improved [[E4/Resources/Work_Areas#Non-Local_Resources|Remote Support]]''' - improved handling of latency, errors, caching; support for remote workspaces; physical/logical path translation
* 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.
+
*** ''Remote, asynchronous'' - Chris (IBM)
* Michael: Different clients have different views on what they want to see in terms of resources. Consider something like "perspectives" on resources which include filtering (working sets) and only deliver notifications for "interesting" stuff. A generalization of current isHidden / isTeamPrivate / ...
+
*** ''Remote Workspaces'' - McQ (IBM)
** Martin: In some sense, such resource perspectives are probably similar to IPreferencesService IScopeContext. Clients pass a context into the APIs, by which they operate. Such Contexts can also provide improved concurrency support, since non-overlapping contexts can modify the workspace at the same time (non-overlapping subject to correct alias management). This could help us get rid of a lot of issues...
+
*** ''RESTful'' - Kenn (Embarcadero)
* Michael: '''In the end, we must come up with a simple set of rules that we can explain to a user. Must fit on a sheet of paper.'''
+
*** ''Mapping URI to physical path'' - Chris (IBM), Doug (Wind River)
** Doug: '''Dont lock ourselves in a single paradigm.''' In addition to today's filesystem-based project content, support file list-based contents. Perhaps a pluggable content provider... EFS could be just such a content provider (See Nokia's experiments so far).
+
** '''Improved [[E4/Resources/Work_Areas#Improve_Concurrency_and_Programming_Model|Programming Model]]''' - more concurrency, more componentization, fewer listeners, listener order and race conditions, no Singletons (See also [[E4/Pervasive Themes]])
** 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.'''
+
*** ''Layered Architecture'' - Michael (Wind River)
 
+
*** ''Getting rid of Singletons'' - Boris (IBM)
=== Galileo vs E4 ===
+
* Adding stuff to Galileo already is compelling, but what about the Risk of creating new complications in terms of compatibility for the "Real solution"?
+
  
 
=== Communication Channels ===
 
=== Communication Channels ===
 
* platform-core-dev mailing list
 
* platform-core-dev mailing list
* eclipse-incubator-e4-dev mailing list
+
* Anything else? Try to attract more people? What about IRC, Bugzilla, E4 list?
* E4 IRC channel
+
* Bugzilla
+
* Anything else? Try to attract more people?
+
  
 
=== Meeting Schedule ===
 
=== Meeting Schedule ===
 +
* Talk on platform-core-dev list
 +
* Will discuss this on CDT Summit
 +
* Next meeting in 2 weeks
  
 
== Action Items ==
 
== Action Items ==
 
+
* [[Image:Ok_green.gif]] '''Martin''': Start [[E4/Resources/Definitions of Terms]] - discuss on platform-core-dev mailing list, put notes together on Wiki
  
 
== Next Meeting ==
 
== Next Meeting ==
 
* Next [[E4/Resources/Meeting/3-Oct-2008]] (2 weeks after)
 
* Next [[E4/Resources/Meeting/3-Oct-2008]] (2 weeks after)

Latest revision as of 08:58, 22 September 2008

Meeting Title: E4 Resources Kick-off meeting
Date & Time: Friday Sep 19, 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, 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
  • Regrets: Broadcom - James Blackburn

Agenda

Feel free to edit, but not during the meeting

DougS on the platform-core-dev mailing list: I'd like to start by getting introductions from everyone on the call including their background and a high level view of what they'd like to see out of e4 resources. Then I'd like to walk through the E4/Resources/Work Areas page, that Martin O. has prepared and see if there anything people have objection to, or items they'd like to add. Please take a look before the meeting. That'll easily take the hour, so I'd like to discuss how often we want to meet and get an idea of things people would be able to work on in between meetings.

Notes

Interested Parties and Background

  • Doug Schaefer: Wanted to enable VS projects in Eclipse, that initial work later carried on by Ken Ryall (Nokia). Idea was a virtual file system similar to EFS. Ran into troubles due to assumptions of clients (external tools) that resources are backed by a physical file system. EclipseCon 2008 discussion picked up by E4 effort.
    • McQ: For making Eclipse more pervasive, E4 gives us the freedom to take a step back without immediate need for backward compatibility
  • Serge Beauchamp: Metroworks CodeWarrior background (similar to VS). Need flexible project structure bug 229633.
    • Martin: It's not decided yet whether E4 will be a vast, big effort -- it will be what we as a community make it. For now, just all items are on the table. All input is valuable!
  • Ken Ryall: Many customers coming from CodeWarrior having file-list based project structure. Want migration into Eclipse. Interested in working on broader changes, did some work on flexible file system prototype in CDT (virtual file system), encouraged by initial results. Interested in 3.5 shorter-term fixes. Customers want standard, unmodified Platform. Scalability and filtering (very large projects)
  • Terry Parker & Tom Ball: Very large code bases on Linux, current model falls down in some cases:
    • Complete refresh of the workspace don't work - HIDDEN attribute doesn't keep resources from being traversed. Want to exclude portions of large underlying file system. IntelliJ can pull the entire codebase in (Eclipse is killed by that)
    • Aliased paths (symbolic links) - canonical form of paths (better comparator) instead of plain Strings
    • Sergey Prigogin: Hiding stuff must be done before EFS, before Resource creation
  • Ken Hussey: Make Resources file system agnostic, more RESTful style of resources. Better Content Types instead of file extensions. Filtering ("what's visible" based on resource sets)
    • Chris, Doug - For external tools and version control, EFS mapping to physical paths is a problem
  • Chris Recoskie: Import existing physical project structures into CDT; Remote Resources;
  • Martin Oberhuber: Bringing large legacy file structures into Eclipse, making it easier for customers to apply Eclipse to their daily work. Physical project nesting, Flexible Projects. Also interested in Architecture but with lower priority.
  • Michael Scharf: 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.
    • DougS: Clearcase remote client has a good workflow. Resource system as a View on something.
    • John Arthorne: Could be several different application layers. One characteristic of EFS is that it's stateless, whereas one big value-add of the Resource model is that it's adding state (markers, sync info, ...) on top of physical.
    • DougS: How to attach metadata that gets checked in? (Coming from the Build angle)
    • Have different types of notifications (on resource layer and application layer)
    • Boris: Currently, notifications are on workspace basis. Might want multiple workspaces.
    • Martin: Multi-workspace also interesting to work on multiple versions of same project (name resolution)
    • McQ: Name resolution inside single workspace would also be interesting.
    • McQ: Using EFS for arbitrary filesystem-like things is pushing it too far. On a remote workspace, it's likely that Build wouldnever have to occur locally. Distributed is interesting, but don't warp this into EFS.
  • McQ: Want to give insight in why things are the way they are, but won't be able to invest lots of resources.
  • Boris Bokowski: Interested in architectural side of things, want to get rid of Singletons
  • Szymon Brandys:
  • Eric Frey: Large user of Eclipse, writing individual tools, want to be Ecilpse based. Need flexible resource and project model (projects in same directory) - based on VS
    • Michael: need to think about what a project is (root dir + meta info) - that's different than the definition of project in other IDE's
    • Doug: Lots of problems in the past in CDT came from trying to apply Eclipse concepts to non-Eclipse worlds -- e.g. Autobuilder. In reality, CDT build does work differently. Looking at modeling stuff in the resource system that can help.
    • McQ: One of the big differentiators of Eclipse to other IDEs is Autobuild, the power of Resource Deltas. This needs to be part of the solution.
    • Doug: Have 2 builders in CDT, one of them based on resource deltas but most people work on external make (which is annoying). Doug wants to fix the architecture such that external builders work better.
  • McQ: What about Logical Model Support that's in place now? Managing sub-file or super-file resources? - Resources can be adapted to ResourceMapping, which describes related resources. Allows writing all of them to repository in one operation.
    • Michael: We need to come up with a common terminology and need to agree on a meaning.
  • Doug: Wants to start talking in terms of work items, and stuff that we want to start prototyping right away. Want more discussion on platform-core-dev mailing list.
    • Where should prototyping happen?
    • Boris: Will get the project created soon.

Galileo vs E4

  • Adding stuff to Galileo already is compelling, but what about the Risk of creating new complications in terms of compatibility for the "Real solution"?
    • McQ is a big fan of adding features early, if it doesn't conflict with the big picture.
    • Most participants will want part features implemented early.

Work Areas

  • E4/Resources/Work Areas - the big rocks:
    • Improved Alias Management - Fix issues with symbolic links / linked resources - multiple nodes pointing to the same content - clarify semantics of aliasing / overlapping
      • Alias Management: Terry, Sergey (Google), James (Broadcom), Martin (Wind River)
    • Improved Project Structure - relative/variable-based linked resources, file-list-based projects, multi-workspace, physical/logical project nesting, namespace resolution, perspectives/filtering
      • Filtering: Sergey, Terry, Tom (Google), Ken (Nokia), Kenn (Embarcadero), Martin, Michael (Wind River)
      • Refresh/Large Workspace Performance: Terry, Tom (Google), Ken (Nokia)
      • Flexible Project Structure: Doug (Wind River), Serge (Freescale), Ken (Nokia), Chris (IBM), Eric (NVidia), James (Broadcom)
      • Physical Project Nesting: Martin (Wind River)
      • Multiple Workspaces: Boris, McQ (IBM), Martin (Wind River)
      • Namespace resolution: McQ (IBM)
      • Multiple Projects in one Dir - Eric (NVidia)
    • Improved Meta Data - More settings levelling, arbitrary metadata attached to resources with persistence or from file system (with lifecycle ala markers), pluggable project/metadata persistence (interoperability with other IDEs)
      • Arbitrary Persistable Data on Resources - Doug (Wind River), for Builders
    • Improved Remote Support - improved handling of latency, errors, caching; support for remote workspaces; physical/logical path translation
      • Remote, asynchronous - Chris (IBM)
      • Remote Workspaces - McQ (IBM)
      • RESTful - Kenn (Embarcadero)
      • Mapping URI to physical path - Chris (IBM), Doug (Wind River)
    • Improved Programming Model - more concurrency, more componentization, fewer listeners, listener order and race conditions, no Singletons (See also E4/Pervasive Themes)
      • Layered Architecture - Michael (Wind River)
      • Getting rid of Singletons - Boris (IBM)

Communication Channels

  • platform-core-dev mailing list
  • Anything else? Try to attract more people? What about IRC, Bugzilla, E4 list?

Meeting Schedule

  • Talk on platform-core-dev list
  • Will discuss this on CDT Summit
  • Next meeting in 2 weeks

Action Items

Next Meeting

Back to the top