The current LXR::Files class has a single global object that represents a backend (plain, CVS, etc.) Methods of this object take a filename/release pair and return various information about that file using that backend.
I don't think this is the proper organization and this should be rearchitected. I propose the following:
1) The current LXR::Files class should be reworked to be a very small class, that just does whatever setup is needed for that backend type. It could be renamed to something like LXR::FileType or something, maybe. It's possible we won't even need this: we'll have to see.
2) A new LXR::File class should be created. An object of this class will represent ONE file/release. It will have various methods to retrieve the path, content, size, etc.; these don't need to take any arguments (generally).
LXR::File is probably going to be a superclass with subclasses for each backend, and the actual objects returned would be objects of the subclass. The LXR::File class would provide basic method implementations (probably similar to today's LXR::Files::Plain class) which various other backends could override.
Once this is done I think a lot of other things, like the web caching described in another feature request, become more straightforward to implement.