That's a perfectly valid way of looking at it -- scaled/reformatted
images as variant representations. As Jerome covered, for
image formats, since each one has its own MIME type and idiomatic
extension that can be used by Directory's existing content
negotiation features, this is quite manageable.
I don't know of existing HTTP semantics that map well to specifying
resolution as a variant, though. So you end up having to decode that
from other information -- the URI or query string as you proposed.
Jerome described a way to do this with a Filter.
I've read quite heated theoretical arguments over whether a scaled
image is a variant or a different resource. In my heart I feel it's
a variant (same "content" on a human level, different resolution)
But I do find it pragmatically easier to address scaled images
(and in fact, different image formats) as separate resources in
almost every daily usage.
The real deal-breaker for me is the fact that image operations may
take longer than timeouts associated with HTTP -- or at least, a
very long time. For my apps, keeping connections open in blocking
state can make typical Web/AJAX stuff unusable -- browsers limit
the connections to a given server, and if one or more are tied up
waiting for a resize operation, bad news for the app!
This may not be a concern for you if you're consuming images you
produce locally and aren't worried about blocking or timing out.
But in my AJAX world, the conversion service can immediately return
the generated URI and then background the operation, leaving it to
the client to backoff/retry in a non-blocking way until the image
becomes available.
One other note: if you do take the approach of having a separate
conversion service from the resource retrieval mechanism, each
conversion operation need not exist at its own URI. You could have
one conversion service that took all the parameters in one go:
format, size, color depth, quality, whatever else your server will
allow.
- Rob
----- Original Message -----
From: "Paul J. Lucas" <[EMAIL PROTECTED]>
To: discuss@restlet.tigris.org
Sent: Thursday, November 15, 2007 11:07:17 PM (GMT-0500) America/New_York
Subject: Re: New user: guidance for server?
On Nov 15, 2007, at 1:24 PM, Rob Heittman wrote:
> For the resizing and conversion operations, that's a larger question
> with some design decisions involved. Here, I think you are combining
> a command ("rescale image {uri-fragment} to maximum dimension {n}")
> with a resource retrieval operation (GET {uri-of-rescaled-image}).
> The approach I'd choose -- in fact, have chosen in actual
> implementations -- is to separate these steps.
Well, my thinking was that the original image is the resource and
either a different scale or a different format is merely a different
representation of the resource. But you're saying to treat the
original image as static and have a separate service (each with its
own URL) that performs some transformation on the original image, yes?
FYI: my server will not rescale/reformat any image at any URL on the
Internet, but instead will only rescale/reformat images it itself
serves.
- Paul
