Questions regarding architecture of a server-based image-pro


I’m planning to deploy a hybrid 2D/3D visual fx and image manipulation
engine as a server accessible via the Web. So you can send Flickr
images to it for all manner of image trickery.
My engine uses a little text-based language I devised that is parsed
and a resultant image produced. The UI for this service collects the
input image and associated params and passes the collection to my
engine where an instance of my language is constructed, parsed, and
resultant processed image returned to the user.

My question regards architecture rather then any specif ROR technical
issue. I am reluctant to wrap it in a Web service as the bulk of the
functionality resides in the actual engine which is written in C++. Is
there a happy middle ground between full blown Web service and
old-school CGI style?

Should I think seriously about making a Ruby binding (ala RMagick) or
is that overkill?

Thanks in advance,
Doug Turner
mobile: 781 775 3708
skype: dduuggllaa

I’d be less concerned about the architecture than I am about providing a
“service” that has the potential to execute arbitrarily complex and
extremely time-consuming image processing algorithms on the server. How
will you defend the processor and the hosting company against this? Are
you charging money for this service and attempting to make a profit
doing so, or are you planning to give this away?

Douglass T. wrote:

Doug Turner
mobile: 781 775 3708
skype: dduuggllaa

Rails mailing list

M. Edward (Ed) Borasky


Actually my concern at this point is architecture, user experience,
etc. Your comment about arbitrarily complex computations presumes I
have not bounded those calcs. I have. The same goes for bandwidth

I’d really appreciate some feedback from the ROR smarties out there.