Taking VirtualFile would certainly help, though this means AbstractProject.getWorkspace cannot work—you would also need to introduce a new set of methods for finding the VirtualFile root to browse.

Also VirtualFile as written is not quite flexible enough, because it assumes that the master should be in charge of retrieving file contents (as bytestreams) and serving them to the client. What we found was necessary also for making an ArtifactManager based on, say, S3 was to allow VirtualFile to optionally designate a replacement URL that would be served directly to clients. (DirectoryBrowserSupport would need to call the new method.) In the context of workspace browsing, this would mean that the master could redirect workspace browse requests (from the root, from individual files, or just from certain subtrees) to other servers that could process the request more directly and efficiently.

Discussion on dev list suggests extending this to allow ComputerLauncher (perhaps) to honor requests to attach a given workspace to a new slave somehow.

Would be good if this were designed with extensibility of the file browser in mind. There are several issues around that are about adding features to the workspace browser (e.g. file permissions on Unix nodes, file modification times, and/or allowing to edit or delete files specific).

If you know of particular issues, please link them.

Linked a few issues that are about extending the workspace (or possibly artifacts) browser, and one bug. I'm fairly sure there's also one for showing file ownership/permissions, but I cannot find it right now.