KnpLabs/Gaufrette — pull request #121 by TomiS (2013-01-08 09:59:02+00:00)
Title: More metadata support and lots of other refactoring/redesign stuff.

This is not for merging, just for discussion!!! Ping @l3l0 and @stof

Ok, so I started doing the metadata implementation. I worked with GridFS but was practically forced to make several modifications to generic ```Filesystem```, ```File``` and ```Adapter``` classes. For example I did following:

- Removed $metadata field from adapters because metadata is feature of a file, not adapter. Adapter handles all files in my understanding. Also removed metadata setters and getters from adapter.
- Added ```writeFile($file)``` and ```readFile($key)``` functions to adapter. This makes it easier to use the library in more object oriented fashion.
- Removed supportMetadata function because it's too simple to really be usable. Added ```isMetadataKeyAllowed($metaKey)``` instead. This is (and should be) a feature of an adapter, not file. This change makes it possible to validate keys more accurately
- Removed create flag from ```Filesystem->get()``` function because imo it's confusing to mix create and read in the same function.
- Removed all Filesystem dependent crud operations from ```File``` object because either all crud should be in File or they should be in Filesystem. In the present state only some of the crud operations were in the file, but not all. In the future File object is only a "dummy" container for file data and the actual magic happens in ```Filesystem```

And there's probably more stuff which I forget... So I think this definitely breaks BC and I understand it might be a problem.

The thing, however, is... I'd even like to go further. I think it's very necessary to improve file object even further. I think the whole structure of the lib should be divided in following way (example is for GridFS):

```
Filesystem.php
Filesystem/GridFS.php
File.php
File/GridFS.php
```

So we wouldn't have one single adapter to handle all stuff but two adapers. One for file and one for filesystem. The file should be very compatible with Symfony's nice File object (and extend SplFileObject if possible). The filesystem should only return file objects and not raw data in any situation. This would make lazy loading the filedata easier for some situations, as well as including metadata for more advanced adapters and even custom CDN systems. (we have a case in hand with this)

Ok, so here are some thoughts. I definitely understand all this might be 'too much' because of the BCB and stuff or if you just feel the lib should move to different direction. If, however, you like these ideas, I'm more than willing to work for this. But if not, I can always make my own lib, no hard feelings :)