On 20/10/11 06:41, Russell Nelson wrote:
In order to support viewing deleted files (currently a
blocker bug in
SwiftMedia), I'm going to refactor File::getPath() into a new public
function File::getLocalPath(), which will return an instance of a new
class TempLocalPath, which will have two methods: getPath(), and
close(). This class will own a local copy of the file. When it goes
out of scope or its close() method is called (same thing), any
resources held by the class will be freed.
With the upcoming FileBackend class and subclasses, this class will be
a requirement. Since I need it anyway, I may as well do the work now
to create it. File::getPath() will remain as a call, but it will throw
an exception if SwiftMedia is installed. When I get finished, its only
uses will be by extension writers who have chosen not to publish their
code in our SVN.
File::getPath() should return false if a local path is not available,
not throw an exception. This is the documented behaviour, and is
already implemented by ForeignAPIFile. Any File::getPath() callers
which don't guard against this should be changed to do so.
The wfStreamFile() callers should call FileRepo::streamFile(), not
File::getLocalPath(), as we previously discussed.
Making a local copy of a file is probably not the most efficient way
to stream the file out to the client, for any backend. So streaming
should be done by the repo, not by a UI module like Special:Undelete.
Finalising a true streaming interface between the FileRepo and the
FileBackend is not essential in the short term, it can be done later
to reduce the scope of the current FileBackend project. But it's
important that external callers use a FileRepo interface which is
flexible and allows for future performance improvements.
-- Tim Starling