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 _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
