E4/Resources/Meeting/19-Sep-2008 Kick-off

Meeting Title:	E4 Resources Kick-off meeting
Date & Time:	Friday Sep 19, 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 #

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

• Martin: Start E4/Resources/Definitions of Terms - discuss on platform-core-dev mailing list, put notes together on Wiki

Next Meeting

• Next E4/Resources/Meeting/3-Oct-2008 (2 weeks after)