[Tramline-dev] Re: Large file handling

[Martijn Pieters]

Martijn Faassen wrote:
>> 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?

Not if you want to scale the setup to a cluster; using WebDAV ensures
that you can keep repository separated from CMS, and keeps the
file-access semantics simpler, actually. No need to juggle groups to be
able to write or delete repository files from your CMS if that is
running under a different account.

If WebDAV is overkill, you can still just access the files directly. In
both cases a 'simple API' for tramline is not needed, keeping tramline
simple. And it's simplicity is it's strong point.

> 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.

It's just that a 'simple API' would still be an indirect layer, and
perhaps limit Tramline to python-implemented CMS-es. Why not make a
WebDAV based layer then, and make it easy for non-python Tramline
integrators. Not adding an API to tramline has the added advantage you
cannot break anything or suffer from scope creep.

>>> 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.

Indeed, and then it gets hairy, what with conditionals and such ;) See
the OFS.Image.File implementation (which largely ignores conditionals
anyway) for the brave souls who want to venture 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.

Exactly. And WebDAV, with a library, *is* a simple API, and
well-understood and implemented in both Apache and IIS.

Martijn Pieters

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://codespeak.net/pipermail/tramline-dev/attachments/20060511/aba6ae37/signature.pgp