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
• IBM - John Arthorne, Szymon Brandys, Chris Recoskie
• Competitrack - Yma
• Embarcadero - Kenn Hussey
• Freescale - Serge Beauchamp
• Intel - Sergey Prigogin
• Nokia - Ken Ryall
• NVidia - Eric Frey

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

• E4/Resources/Requirements, Use-Cases and Goals

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
    • A layer of its own that can be added/removed?
  • Improved 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?
  • 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)
    • Another pluggable layer?
  • Improved Remote Support - improved handling of latency, errors, caching; support for remote workspaces; physical/logical path translation
  • Improved Programming Model - more concurrency, more componentization, fewer listeners, listener order and race conditions, no Singletons (See also E4/Pervasive Themes

Some random architectural ideas

• 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()?
• 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.
• 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 / ...
• 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.
  • 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).
  • 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.

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

• platform-core-dev mailing list
• eclipse-incubator-e4-dev mailing list
• E4 IRC channel
• Bugzilla
• Anything else? Try to attract more people?

Next Meeting

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