|
|
| (19 intermediate revisions by 6 users 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)
| + | The E4 Resources work is about improving Eclipse Platform [[Resources]], |
| − | ** Inclusion of Files from Anywhere on the file system
| + | both in terms of '''APIs and end-user usability'''.<br/> |
| − | ** Full Native Support for Symbolic Links (avoiding problems with cyclic symlinks)
| + | The '''Flexible Resource Model''' is especially about making the |
| − | ** Add/remove project type/nature
| + | concept of a '''Project''' more flexible. |
| − | ** 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?
| + | '''The Goals''' are listed in detail on the [[E4/Resources/Requirements|Requirements]] page, in short: |
| − | ** Content Types:
| + | * Make the Workspace, Project and Resource structure flexible enough to embrace any existing (legacy) structures. |
| − | *** Pattern Matching for content types rather than just file extensions + stream evaluation | + | * Build an architecture that's easy to understand, reliable, simple and safe to code against. |
| − | *** Case sensitive patterns for content types
| + | * Support future environments (client/server, distributed, web, collaborative) - building a solid base of Eclipse for the next 10 years. |
| − | *** UI for Project-specific content types
| + | |
| − | * Some ideas that came out of the modeling session | + | '''Interested Parties:''' (alphabetically) - See also the [[E4/Resources/Meeting/19-Sep-2008 Kick-off#Interested_Parties_and_Background|Kick-off meeting]]: |
| − | ** Need a model for the resource system
| + | * Broadcom, Cloudsmith, Embarcadero, Freescale, Google, IBM, Nokia, NVidia, Wind River |
| − | ** Need extensible so we can add project properties that get persisted with the project
| + | * Component Lead: '''Doug Schaefer (Wind River)''' |
| − | *** 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?
| + | '''Documents:''' |
| − | *** How is this persisted?
| + | * [[E4/Resources/Strawman]] - Strawman proposal |
| − | ** Using DOM/CSS type thing, we can auto generate the project explorer
| + | * [[E4/Resources/Brainstorming]] - Notes and Ideas from early meetings |
| − | ** Support existing API as facade?
| + | * [[E4/Resources/Comparison]] - Comparison of Eclipse with other systems |
| − | ** Does EFS become simpler? necessary? if model is extensible
| + | * [[E4/Resources/Requirements]], Use-Cases and Goals |
| − | ** Flexible support - Add/excludes recorded in model
| + | * [[E4/Resources/Definitions of Terms]] |
| − | * Some Possible Requirements (please feel free to add new ones here)
| + | * [[E4/Resources/Work Areas]] - Planning |
| − | ** Flexible
| + | ** {{bug|252647}} is the master plan item. Look for bugs blocking on that one. |
| − | *** include/exclude resources explicitly, optionally with children (do we need more comprehensive filtering schemes?)
| + | * [[E4/Resources/Meeting Notes]] - Our meetings are on the E4 Calendar. |
| − | **** 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
| + | </td> |
| − | **** 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.
| + | <td valign="top" width="33%"> |
| − | *** Virtual resources
| + | |
| − | **** In other words, break the assumption that the resource model maps nearly one-to-one with the underlying filesystem
| + | <h3>Communication Channels</h3> |
| − | **** Multiple projects should be able to reference the same physical file. Projects should be able to overlap. | + | * [https://dev.eclipse.org/mailman/listinfo/platform-core-dev platform-core-dev mailing list] |
| − | *** Nested projects should be possible | + | * [[E4/Resources/Meeting Notes]] |
| − | *** non local projects/resources first class citizens
| + | * Bugzilla as per the [[E4/Resources/Work Areas]] |
| − | *** non-physical projects/resources first class citizens
| + | * ...as well as the other [[E4]] communication channels |
| − | *** 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)
| + | <googlecalendar width="100%" height="300" mode="AGENDA" title="e4 Calendar">ctri5teoag0n87t2qu9bla8u3g%40group.calendar.google.com</googlecalendar> |
| − | *** More flexible content type schemes
| + | This calendar is available in the following formats:<br> |
| − | **** e.g. for MVS, which doesn't have file extensions
| + | [[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] |
| − | ** Portable (projects/workspaces) | + | </td> |
| − | *** between users/machines/locations | + | </tr> |
| − | *** no absolute paths embedded in project files | + | </table> |
| − | ** Consumable
| + | |
| − | *** grouping of projects
| + | [[Category:E4|Resources]] |
| − | *** 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
| + | |
