|
|
| (18 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| − | <h1>Flexible Resource Model</h1>
| + | __NOTOC__ |
| | | | |
| − | * From [[Architecture Council/Minutes May 15 2008#Workspace, Resources, Content_Types]]:
| + | <table border="0" width="100%" cellspacing="6"> |
| − | ** Project Nesting
| + | <tr> |
| − | *** Physically: Allow .project file below another .project file be separate full-blown projects -- break iterating over outer's children when finding a project
| + | <td valign="top" width="66%"> |
| − | *** Logically: Have nested project inherit Preferences from outer project
| + | |
| − | ** Namespace Resolution (multiple projects with same name in a workspace)
| + | |
| − | ** Inclusion of Files from Anywhere on the file system
| + | |
| − | ** Full Native Support for Symbolic Links (avoiding problems with cyclic symlinks)
| + | |
| − | ** Add/remove project type/nature
| + | |
| − | ** Listeners and plug-in Loading
| + | |
| − | ** Getting rid of Project for RCP (see also [[e4/RCP Future]]) -- is the notion of "Project" a plumbing or User Artifact? Where should builders etc be hung off?
| + | |
| − | ** Content Types:
| + | |
| − | *** Pattern Matching for content types rather than just file extensions + stream evaluation
| + | |
| − | *** Case sensitive patterns for content types
| + | |
| − | *** UI for Project-specific content types
| + | |
| − | * Some ideas that came out of the modeling session
| + | |
| − | ** Need a model for the resource system
| + | |
| − | ** Need extensible so we can add project properties that get persisted with the project
| + | |
| − | *** e.g. so we can get rid of maintaining our own .cdtproject file for the CDT
| + | |
| − | ** EMF? Are we ready for IResource to be an EMF object?
| + | |
| − | *** How is this persisted?
| + | |
| − | ** Using DOM/CSS type thing, we can auto generate the project explorer
| + | |
| − | ** Support existing API as facade?
| + | |
| − | ** Does EFS become simpler? necessary? if model is extensible
| + | |
| − | ** Flexible support - Add/excludes recorded in model
| + | |
| − | * Some Possible Requirements (please feel free to add new ones here)
| + | |
| − | ** Flexible
| + | |
| − | *** include/exclude resources explicitly, optionally with children (do we need more comprehensive filtering schemes?)
| + | |
| − | **** keeps the project file small as if you know you want all children of a folder the project file only needs to store the location of the folder you added and not individual links for all the children beneath it)
| + | |
| − | *** Virtual content in resource model
| + | |
| − | **** Don't scan for resources until they're asked for. Right now the workspace refresh policy of "refresh the entire project when opened" makes things really slow when you are using EFS to a remote share.
| + | |
| − | *** Virtual resources
| + | |
| − | **** In other words, break the assumption that the resource model maps nearly one-to-one with the underlying filesystem
| + | |
| − | **** Multiple projects should be able to reference the same physical file. Projects should be able to overlap.
| + | |
| − | *** Nested projects should be possible
| + | |
| − | *** non local projects/resources first class citizens
| + | |
| − | *** non-physical projects/resources first class citizens
| + | |
| − | *** May have many to one relationship between workspace resources and physical resources (e.g. look at how opening plugin.xml also lets you edit manifest.mf in one logical editor)
| + | |
| − | *** More flexible content type schemes
| + | |
| − | **** e.g. for MVS, which doesn't have file extensions
| + | |
| − | ** Portable (projects/workspaces)
| + | |
| − | *** between users/machines/locations
| + | |
| − | *** no absolute paths embedded in project files
| + | |
| − | ** Consumable
| + | |
| − | *** grouping of projects
| + | |
| − | *** with or without metadata
| + | |
| − | **** Need to store data that dictates how to make the project successfully function, but want to omit preferences that amount to user "taste," e.g. need to save build settings, but not what colour the build output is printed with in the console.
| + | |
| − | *** Users want toopen a single "workspace file" a la Visual Studio
| + | |
| − | ** Team
| + | |
| − | *** Team has to work in the context of the new project/resource model or developers will not use it.
| + | |
| − | *** Broken even for current scenarios, wants the root of what it checks out to be the project
| + | |
| − | * Minutes From Meeting at e4 Summit
| + | |
| − | **Issues
| + | |
| − | *** projects are currently fundamental(you need one) and heavily overloaded
| + | |
| − | *** resources == filesystem
| + | |
| − | *** need a mapping from model in workbench to what a particular tool (internal/external) needs
| + | |
| − | *** no nested projects
| + | |
| − | *** need flat projects
| + | |
| − | *** dependencies not modeled
| + | |
| − | *** aggregation of projects
| + | |
| − | *** .project file not extensible currently
| + | |
| − | *** can't have multiple workspaces on the go at the same time - need preference scoping for prefs that span workspaces
| + | |
| − | *** import/export is a clunky flow
| + | |
| − | *** need non-physical files
| + | |
| − | *** need non-EFS extensibility
| + | |
| − | *** need to make it so things like RSE can be simpler (no more magic, hidden project for cached files)
| + | |
| − | *** resources need to be "on demand" and lazily loaded, model must allow you to know what is/is not loaded
| + | |
| − | *** want workspace file/Visual Studio "solutions"
| + | |
| − | *** EFS and resource structure are not known by external files
| + | |
| − | *** want to team things, build things, separate things
| + | |
| − | *** working sets not complete
| + | |
| − | *** IResource and EFS are both synchronous, need asynchronous
| + | |
| − | *** resource hierarchy should be a DAG
| + | |
| − | *** URIs are often non-portable as they can embed connection and user authentication info, which means the project can not be portable between users/machines
| + | |
| − | ** Things to watch out for
| + | |
| − | *** import/export
| + | |
| − | *** team
| + | |
| − | *** compare
| + | |
| − | *** build
| + | |
| − | *** search
| + | |
| − | *** markers
| + | |
| − | *** editors
| + | |
| − | *** performance/scalability
| + | |
| − | *** Resource/workspace operations: new, rename, delete, copy, move
| + | |
| | | | |
| − | [[Category:E4]] | + | The E4 Resources work is about improving Eclipse Platform [[Resources]], |
| | + | both in terms of '''APIs and end-user usability'''.<br/> |
| | + | The '''Flexible Resource Model''' is especially about making the |
| | + | concept of a '''Project''' more flexible. |
| | + | |
| | + | '''The Goals''' are listed in detail on the [[E4/Resources/Requirements|Requirements]] page, in short: |
| | + | * Make the Workspace, Project and Resource structure flexible enough to embrace any existing (legacy) structures. |
| | + | * Build an architecture that's easy to understand, reliable, simple and safe to code against. |
| | + | * Support future environments (client/server, distributed, web, collaborative) - building a solid base of Eclipse for the next 10 years. |
| | + | |
| | + | '''Interested Parties:''' (alphabetically) - See also the [[E4/Resources/Meeting/19-Sep-2008 Kick-off#Interested_Parties_and_Background|Kick-off meeting]]: |
| | + | * Broadcom, Cloudsmith, Embarcadero, Freescale, Google, IBM, Nokia, NVidia, Wind River |
| | + | * Component Lead: '''Doug Schaefer (Wind River)''' |
| | + | |
| | + | '''Documents:''' |
| | + | * [[E4/Resources/Strawman]] - Strawman proposal |
| | + | * [[E4/Resources/Brainstorming]] - Notes and Ideas from early meetings |
| | + | * [[E4/Resources/Comparison]] - Comparison of Eclipse with other systems |
| | + | * [[E4/Resources/Requirements]], Use-Cases and Goals |
| | + | * [[E4/Resources/Definitions of Terms]] |
| | + | * [[E4/Resources/Work Areas]] - Planning |
| | + | ** {{bug|252647}} is the master plan item. Look for bugs blocking on that one. |
| | + | * [[E4/Resources/Meeting Notes]] - Our meetings are on the E4 Calendar. |
| | + | |
| | + | </td> |
| | + | <td valign="top" width="33%"> |
| | + | |
| | + | <h3>Communication Channels</h3> |
| | + | * [https://dev.eclipse.org/mailman/listinfo/platform-core-dev platform-core-dev mailing list] |
| | + | * [[E4/Resources/Meeting Notes]] |
| | + | * Bugzilla as per the [[E4/Resources/Work Areas]] |
| | + | * ...as well as the other [[E4]] communication channels |
| | + | <googlecalendar width="100%" height="300" mode="AGENDA" title="e4 Calendar">ctri5teoag0n87t2qu9bla8u3g%40group.calendar.google.com</googlecalendar> |
| | + | This calendar is available in the following formats:<br> |
| | + | [[Image:Ical.gif]][http://www.google.com/calendar/ical/ctri5teoag0n87t2qu9bla8u3g%40group.calendar.google.com/public/basic.ics iCal],[[Image:Xml.gif]][http://www.google.com/calendar/feeds/ctri5teoag0n87t2qu9bla8u3g%40group.calendar.google.com/public/basic ATOM News Feed],[[Image:Html.gif]][http://www.google.com/calendar/embed?src=ctri5teoag0n87t2qu9bla8u3g%40group.calendar.google.com&ctz=Canada/Toronto HTML] |
| | + | </td> |
| | + | </tr> |
| | + | </table> |
| | + | |
| | + | [[Category:E4|Resources]] |
