Hi Ruben / Boris,
Yes - We do things in a similar way to Ruben - editors upload hi-res
versions of images, which are stored in the repository - when the
image is displayed in a paragraph generates a url which specifies the
resolution / encoding required and a servlet resizes/crops/re-encodes/
caches the image on demand and serves the actual data to the client.
Unfortunately, storing originals in the repository and re-encoding on
demand isn't really practical for movies, and so we have a different
system - movie files get uploaded to S3 and then the S3 URL gets
pasted into a "quicktime movie" paragraph on a page. It works, but
it's a hassle for users - they have to upload the movie separately
from their normal magnolia editing, copy and paste the URL, and then -
because the paragraph doesn't know the content of the URL - they have
to hand edit the resolution and specifications of the movie etc. etc.
A plugable backend file system for the DMS would allow media to be
uploaded and managed from within magnolia. Abstracting the DMS file
system would surely be useful for all sorts of other purposes too.
Boris - OnAir sounds really great, but unfortunately I wouldn't have
the budget to afford it, and the editing features wouldn't really be
required - all of the content being uploaded will generally have been
edited in Final Cut anyway, and in our situation there isn't really
much need for simple trimming of content after that. If you could
point me in the right direction to creating a pluggable backend for
the DMS then I'd definitely consider writing that and making it
available.
Josh
On 29 May 2009, at 15:09, Boris Kraft wrote:
Ruben
OnAir doesn't store the assets in the repository, it uses an
external system. So the interesting part is that you can seamlessly
plug in such a system - you use all of STK, but for assets you can
configure different controls (and model class for the link resolving
etc).
You'll like it, I am pretty sure ;-)
- B
On May 28, 2009, at 12:45 AM, Ruben Reusser wrote:
Joshua/Boris:
We tend to use data uploads that just reference a file in S3
instead of putting the file actually into the repository itself. We
then serve the files from other locations for caching purposes and
to make sure we do not go through tomcat/magnolia for static files.
This also allows us to convert the files into a set of formats on
the fly when saving them (all the resolutions we need) and
eliminates the potential for GIFAR Style (Gif Combined with Jars,
potential for all top/bottom reading file types) attacks [1].
Ruben
[1] http://hackaday.com/2008/08/04/the-gifar-image-vulnerability/
Boris Kraft wrote:
Joshua
just two notes
a) look at http://www.magnolia-cms.com/onair - it solves these and
many other issues (and allows you to edit video right in your
browser)
b) with 4.1 we have "virtualized" the DAM such that the STK
specifically can use pluggable implementations to manage its
digital assets. We ship with support for file upload, DMS and
OnAir. I would love to see a plugin for your setup!
Cheers
Boris
On Apr 6, 2009, at 4:28 PM, Joshua Portway wrote:
Has anyone tried to set up a system whereby the DMS uses Amazon
S3 to store and serve files?
I have a site that currently uses Magnolia for managing most of
it, but has quite a lot of movie content - the movie files are up
to 600mb in size, and need to stream smoothly, hence I currently
use Amazon S3 storage + Cloudfront content delivery network. The
solution works pretty well, but the problem is that there's no
way to manage the movie files from within Magnolia, which makes
uploading and changing movies complex, time consuming and error
prone.
Is there any way to change the back end file system used by the
DMS to use S3 (or something similar)?
My idea would be that the DMS would keep metadata about files in
the database, but actually store the files on S3 (perhaps with a
local master copy too, just so that everything is in one place
for migrations etc). When a file was requested it would return
the S3 URL for the file so it would be served directly from
Amazon through their content delivery network.
Josh
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
