Skip to main content
Jump to: navigation, search

Difference between revisions of "E4/Resources"

< E4
Line 84: Line 84:
*** performance/scalability
*** performance/scalability
*** Resource/workspace operations:  new, rename, delete, copy, move
*** Resource/workspace operations:  new, rename, delete, copy, move

Revision as of 15:31, 23 May 2008

Flexible Resource Model

  • From Architecture Council/Minutes May 15 2008#Workspace, Resources, Content_Types:
    • Project Nesting
      • Physically: Allow .project file below another .project file be separate full-blown projects -- break iterating over outer's children when finding a project
      • 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 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

Back to the top