#17 Rearchitect the LXR::Files class to LXR::File

[Paul D. Smith]

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.

[Malcolm Box]

Logged In: YES
user_id=215386
Originator: NO

Excellent idea, this would make a bunch of things easier and be higher performance with certain SCM systems.