[Oliver]
You might want to stream multimedia files with a streaming server but manage them in zope,
[Shane]
To do this, we'd need minimal support from the application. OFS.File needs to delegate the specifics of data storage and retrieval to a subobject. Ape could take the opportunity to replace that subobject with something that reads and writes the file directly.
[Oliver]
But this doesn't expose enough, what you'd need would be something like an "external path", which could be the filesystem path in case of Ape or something more exotic when you are using other storages, which offer alternative ways to serve their data (oracle file system for instance).
Here's what I have in mind. Simplified, OFS/File.py would change to something like this: class SimpleFileData: def __init__(self, bytes): self.bytes = bytes def send(self, RESPONSE): RESPONSE.write(self.bytes) class File(SimpleItem): def upload(self, data): self.data = SimpleFileData(data) def __call__(self, RESPONSE): self.data.send(RESPONSE) An Ape mapper could replace the self.data attribute with an instance of the following class. The mapper would supply the filesystem path to the instance through the constructor. class StreamedFileData: def __init__(self, path): self.path = path def send(self, RESPONSE): bytes = open(path, 'rb').read() RESPONSE.write(bytes) An even better implementation of StreamedFileData would arrange for the file to be sent asynchronously, but HTTPResponse doesn't currently expose such an API.
Since this information is only known to the storage, but can be valuable, there should be a way to get it.
What I'm suggesting is that the storage might transparently enhance the application. On second thought, though, maybe that's not a good pattern, since it might surprise someone to find a StreamedFileData when they expected a SimpleFileData instance. Maybe this stuff should stay at the application layer. Shane