Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Eclipse File Service APIs Compared

Revision as of 04:59, 29 May 2006 by Mober.at+eclipse.gmail.com (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

This page compares features and use cases for remote file access APIs that are currently found in Eclipse. This document is under construction, not finished yet.

RSE Files API

  • viewcvs: IFileService.java
  • viewcvs: IHostFile.java
  • Supports remote move, remote copy operations
  • Categorization of remote files, including support for symbolic links (derived classes of IHostFile)
  • Use Strings as canonical pathes (with '/' file separator)
  • Very lightweight and simple to implement since only Strings and two interfaces
  • Synchronous operations for upload, download (with IProgressMonitor, suitable for jobs)
  • No callbacks or other "watch" facilities
  • Supports remote file encodings different from local

Eclipse Filesystem (EFS) API

  • viewcvs: IFileStore.java
  • Overview on bug 106176 plan: provide more flexible workspaces
  • Existing sample implementations for ZIP and FTP file systems
  • Fully integrated with Platform Resources, allows transparent access to remote files
  • Fully abstract notion of remote pathes through URI for the root, plus parent/child relationships for the siblings
  • Supports remote move, remote copy operations
  • Synchronous operations for upload, download (with IProgressMonitor, suitable for jobs)
  • Originally written for performance optimizations on the local file system (through native calls), plus fully abstract access to remote file stores like databases
  • No notion of symbolic links or other advanced attributes
  • No callbacks or other "watch" facilities
  • URI has been criticized to be heavy-weight (but is only needed to specify the filesystem root, not necessarily the siblings)
  • Registered via extension point - problematic if multiple different implementations for the same access scheme exist, e.g. two implementations for "ftp:" access scheme in URI

Team/Target Management API

  • Will be dropped in favor of EFS, according to the Platform/Team group.
  • Will then provide FTP and WebDAV implementations for EFS

ECF fileshare API

  • asynchronous

Back to the top