Hi,
We have licensed Cute Editor for a large client who intends to publishes the content produced by Cute Editor users as both emails and webpages. When it comes to emails we hope to host the in-line images on our web servers. Because these images may be hit by quite a few people (well, probably in the thousands in the upper limits, it's a corporate announcement tool for sales forces out in the field) so we initially designed the software to store the pictures as uploaded into the file system. Some examples:
1. User opens Cute Editor, write some copy into the Cute Editor composer:
<DIV> hi</DIV>
2. Place an image into the composer using Cute Editor's image uploader:
2.1. We create some folders: InlineAttachments/someGUID
2.2. Assign Cute Editor to use them.
2.3.a Cute editor uploads Blah.jpg into InlineAttachments/someGUID
2.3.b. and writes the following tag into the HTML Source of the composer.
<DIV> hi</DIV><IMG SRC="http://127.0.0.1/VirtualApp/InlineAttachments/someGUID/Blah.jpg"/>
We sends out this html source as body of an email, and we hope the URL points back to the webserver where the images are being served.
We were thinking this is pretty clever because the images would be served really fast. Without hitting the DB.
3. But now we run into a problem when we move the images uploaded to a network share.
and physically like this (by telling Cute Editor what image path to use)
~/
InlineAttachmentsShare.
3.1 We then try to upload and place an image in-line into the Composer.
3.2.a. It uploads it fine.
3.2.b.
But once the uploader pop-up window closes it writes something else into the HTML Source file:
somewhere in the someGUID.
Can this be fixed or must we look at some other alternatives? I have searched the board extensively and people talk about database-backed image serving. Will that work really well on clusters?
This code has gone into production, broken the cluster, and our clients are breathing down our necks. I hope we can get some attention on this, any help would be highly appreciated!!
Best personal regards,
-- David