From faassen at infrae.com Mon May 8 12:32:27 2006 From: faassen at infrae.com (Martijn Faassen) Date: Mon May 8 12:32:12 2006 Subject: [Tramline-dev] Configuring Tramline In-Reply-To: <20060427125800.GE10326@pareto69.pareto.nl> References: <20060427125800.GE10326@pareto69.pareto.nl> Message-ID: <445F1E3B.2090405@infrae.com> Jeroen Vloothuis wrote: > Hi, > > A few things like paths are now hardcoded in Tramline. These things > could/should be made configureable. One thing we could do is place > these in the Apache conf using PythonOption statements. Info on these > can be found here: > > http://www.modpython.org/live/mod_python-3.1.2b/doc-html/dir-other-po.html > > An advantage to using this over external config files would be that > this is in the same place as all the other Apache settings. It also > should allow for a virtual host setup with multiple distinct Tramline > settings. > > What do you think, should we change the hardcoded settings to use > PythonOption's? Yes, I think we should do this. Patches (with tests) are welcome. Sorry about the delay in processing the last patch, I will try to get around to this during this week. Regards, Martijn From faassen at infrae.com Thu May 11 16:50:57 2006 From: faassen at infrae.com (Martijn Faassen) Date: Fri May 12 14:25:57 2006 Subject: [Tramline-dev] Re: Large file handling In-Reply-To: <44632E06.7040303@zopatista.com> References: <44623073.5090608@plonesolutions.com> <44631DC9.5080407@infrae.com> <44632E06.7040303@zopatista.com> Message-ID: <44634F51.2090908@infrae.com> [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 From mj at zopatista.com Thu May 11 17:11:14 2006 From: mj at zopatista.com (Martijn Pieters) Date: Fri May 12 14:25:57 2006 Subject: [Tramline-dev] Re: Large file handling In-Reply-To: <44634F51.2090908@infrae.com> References: <44623073.5090608@plonesolutions.com> <44631DC9.5080407@infrae.com> <44632E06.7040303@zopatista.com> <44634F51.2090908@infrae.com> Message-ID: <44635412.6060004@zopatista.com> 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