[Tramline-dev] Re: Large file handling

[Martijn Faassen]

[taking this to tramline-dev]

Martijn Pieters wrote:
> Martijn Faassen wrote:
> 
>>Tramline needs an API for file access that applications like Zope can
>>use to access files directly given the Tramline id. That's not needed
>>for upload and download, but it is needed when applications need to do
>>things with tramlined-content.
> 
> Simply allowing served hosts (localhost usually) to access the
> repository dirs via WebDAV would do the trick. This leverages existing
> Apache infrastructure, uses a well-known and standard API and keeps
> Tramline simple.

I personally wouldn't want to have to do a HTTP request and a download 
just in order to get access to the contents of a file (or change it). 
Doesn't sound very efficient compared to just opening the file on the 
filesystem?

I'm more thinking about a very simple repository API. That doesn't 
preclude the use of WebDAV but I wouldn't want to require it just for 
the application to get access to a file for, say, indexing purposes.

>>Other ideas would be virtual hosting
>>support - sites on different virtual hosts might want to use different
>>physical repositories on disk. 
> 
> Moving repository path configuration to the Apache VH config should take
> care of that.

True, that should work; I hadn't thought of that.

>>It'd also be nice if someone could look
>>into how Tramline interacts with browser download resume functionality.
> 
> I'd expect this to be a simple Range request, which prolly get's
> ignored; the underlying CMS cannot satisfy the header, as it doesn't
> have the file, and Tramline has no support for it.

Right, but Tramline has the file, so it could possibly grow support.

>>On the Zope 2/Zope 3/Archetypes/Plone end of things, work could be done
>>to make tramlined files as indistinguishable as possible from
>>non-tramlined files in the ZODB from the API perspective, so that
>>application programmers really can stop caring about the difference on
>>that end as well. I imagine each framework (Zope 3 schemas, Archetypes,
>>etc) needs its own solution there.
> 
> For Archetypes we are using a dummy File object; with a WebDAV enabled
> tramline configuration we'd simply extend that object to access the tl
> repository on reads. Even writing to the 'file' could work that way.

Hm, it still sounds a layer too many for me. Of course we could just 
have a repository API and have multiple implementations, one of which 
would use the filesystem directly and another one could use WebDAV. 
WebDAV would have the benefit of allowing the file repository to be on a 
separate machine as the web app, in theory.

Regards,

Martijn