RE Images

Hey Dan

I think this is a cracking idea, something that Radiant really needs is
coherent asset management. How you have outlined it below is exactly as
I
would see it working also! However, im not sure of the value of the
image
manipulation bits and bobs ­ im guessing this will require Rmagick or
something similar? Maybe it would be a good idea to make the
manipulation
stuff optional, so take it or leave it kind of thing.

I think its a great idea on the whole however! I would be really
interested
in making this work. Have you started coding it up yet?

Thanks

Tim P.
lead systems developer

/****************************************************/

Date: Mon, 19 Jun 2006 14:34:55 +1000
From: “Daniel S.” [email protected]
Subject: [Radiant] Images
To: [email protected]
Message-ID:
[email protected]
Content-Type: text/plain; charset=“us-ascii”

I’ve totally got to stop letting myself get distracted - but at least
this is something that I will actually need, and I thought I might push
ahead with this first as it’s got more immediate benefit to the core
product than my other changes.

Adding Images (and other things, in general ‘assets’). I’m going to
actually go ahead and implement this over the next week or so in some
shape or form, and would like to get some feedback on the following in
before I start coding things up (if I don’t get feedback, I’ll just go
with whatever I think is right… I’ll indicate which way I’m currently
leaning):

  1. Storing of assets
    Should this be in the database or on the filesystem? I’m leaning towards
    the db angle, just to have everything in the one place. Caching will put
    it on the filesystem, but the db should be master I think. Conversely, I
    don’t know how stable the blob support in the databases and their
    respective rails connectors is, and there can also be resource problems
    unmarshalling large assets from the database (does activerecord let you
    stream a blob out of the db?), so it might be very resource-hungry to
    pull out a large pdf for example. Anybody have much rails-based
    experience with blobs?
    http://www.voxclandestina.com/computing/ruby/rails/2005-05-24/improving-
    activerecord-part-1/ suggests this might be a bad idea, but I don’t
    think we need to worry too much because a) the userbase for the admin
    pages is low b) it’s rare to put something over a meg or 2 on a website
    (isn’t it?), c) rails caching should handle putting the asset onto disk
    for fast serving. I’d intend of having the asset data in a separate
    table from the metadata, so looking up the list of assets shouldn’t be
    affected by having blobs about.

  2. Administration of assets
    Should an asset just be another page in the sitemap or should it be
    something that you manage actually on the page itself? This is probably
    the big question. It makes a lot of sense to be able to add assets to a
    page while you’re entering the content - “blah blah blah history of
    france blah, picture of france, blah” - you’d probably want to be able
    to add the image at that point rather than finishing up the article and
    then having to add images on the sitemap screen. Conversely, being able
    to manage assets through the sitemap screen gives you a nice unified way
    of looking at the site, and using the single-table-inheritance stuff
    that I’m planning should allow an asset to basically be ‘just another
    page’. in the site - which really it is. I’m probably going to go down
    the second path, but might add some stuff to the page editing screen to
    be able to manage assets from there too (using an iframe-based popup so
    as not to interrupt editing - have a look at what livejournal does).

  3. Image manipulation - I’m thinking of putting together a controller
    that behaves somewhat similar to amazon’s image manipulation code (see
    http://aaugh.com/imageabuse.html) - this would make things very
    flexible, allowing you to write things like "<r:image path=“bob_geldof”
    size=“600x”> and have that translated into a url that the
    ‘AssetController’ class could then interpret to create a string of
    manipulations to the image/asset (though I don’t really know what
    manipulations would be used for a non-image asset). Initially this will
    just consist of resizing, rotation and possibly drop-shadows, but
    hopefully I can figure out a way to make it plugin-based so you can do
    all the other amazon-like magic (overlay %off images, or whatever other
    manipulations you can think of).
    The only downside to this is that you’d open yourself up to people
    abusing your image manipulation libraries and eating up all your
    resources, but I might introduce some check-summing code to make sure
    that you can only do the manipulation if you have access to a shared
    secret (ie, so the <r:image> tag would know the secret and add the
    checksum param but if you tried changing settings as an end-user you’d
    end up with an invalid manipulation string).


This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:

I agree, this is a great idea. My input is that you keep this as a
separate piece and like Tim was saying keep the image manipulation to
a minimum or separate also. Try to keep the asset management simple
and clean. I do think however since this would entail images as well
as pdf and other documents you would want at least a 10MB limit,
1-2megs is small. I would vote to keep the assets out of the database
for speed issues.

Chris-

On Jun 19, 2006, at 7:23 AM, Tim P. wrote:

manipulation

with whatever I think is right… I’ll indicate which way I’m
don’t know how stable the blob support in the databases and their
think we need to worry too much because a) the userbase for the admin
something that you manage actually on the page itself? This is
unified way
that behaves somewhat similar to amazon’s image manipulation code (see
all the other amazon-like magic (overlay %off images, or whatever

Radiant mailing list
[email protected]
http://lists.radiantcms.org/mailman/listinfo/radiant

Chris Corriveau: CTO of Genevate - P.O. Box 1829, North Falmouth,
MA 02556
contact | [email protected] - 508.564.5676 ext. 202 | toll free -
866.GENEVATE
Visit: CapePropertySearch.com has graphs and trends on over 6,500+
Cape Cod properties.

When putting files on a filesystem, please keep in mind that many
filesystems become incredibly slow when you’re using more then a couple
of hundred files in a directory.

 Erik.

On 6/19/06, Erik van Oosten [email protected] wrote:

When putting files on a filesystem, please keep in mind that many
filesystems become incredibly slow when you’re using more then a couple
of hundred files in a directory.

One way to handle this (that I’ve used in the past) is to expand the
id of the asset to a reasonably large number of digits (zero padded)
and split it into several subdirectories.

Example w/ 10 digits: Asset with id of ‘1134’ is placed in directory
assets/00/00/00/11 as ‘34’

Not sure if this is the solution to the problem, but it’s what I use.

Cheers,
Bruce