Described in detail on the Platform/Team
team web site.
See also bug 37722.
Questions and Issues
- How to manage the file system provider mapping to the resources?
- How is this information persisted?
- Should this information be shared in the repository?
- How do we store folder-level metadata? (do we need to do this?)
- If so, then what differentiates a project from a folder?
- How do we handle linked resources?
- How do we provide access to the Core library calls?
- Do we need startup/shutdown lifecycle events to allow for cleanup?
- How do we deal with missing providers?
- DefaultProvider could be an abstract class for others to inherit from.
- Register data providers via an extension point.
- The relationship between TeamProviders and DataProviders is yet to
be defined, but we would like to keep knowledge team out of Core as
much as we can. It is thought that perhaps TeamProviders should be able
to answer their "preferred data provider".
- Take a look at the current Move/Delete hook implementation. With this,
there are basically 2 ways of doing things. You can either do some pre-processing
and then defer the actual operation to the default (by calling IResourceTree.standardFileDelete,
etc) or the operation is broken into 2 separate pieces. The implementor
of the Move/Delete hook performs the file-system based part of the function
and then makes the appropriate calls back into the resource tree in
order to update the workspace.
Sample Data Providers and their requirements
- ignore files in all CVS folder subtrees
- pre-notification of all resource operations
- opportunity to override any/all resource operations (create, delete, move, copy)
- part of logical to physical problem?
- #members looks inside a zip file, #create adds to the zip file, etc
- how do you handle resource types? the zip file is a FILE but has members
- don't allow modifications to project contents (treat projects as read-only)
- ignore files based on type/extension