attachment work
Mark Hammond
your DB (and blob store)
* Attachments in emails are handled much better. The 'visible' flag is
likely to be correct (ie, should be false on most 'inline' images). It
is currently also true for *all* links.
* There is an API demo of the image attachments which was cloned from
Bryan's 'link' demo. Visit http://127.0.0.1:5000/sketches/images.html
after synching to see it. It shows 'thumbnails' and 'previews' with a
link to the original image for all visible attachment images.
* I haven't changed the concept of "type" in attachments, but it seems
we really do want to do something here - eg, it should be possible for
the 'images' demo to also show images from links in the message (with
'thumbnails' etc) - currently that is impossible.
* All *visible* image attachments now have 'preview' and 'thumbnail'
representations created as they were in the couch raindrop. To cut a
long story short, these attachments now have a json representation which
looks something like:
{
type: "image",
subtype: "png",
name: "foo.jpg", // the filename used to attach the image
url: "some://url" // a URL where the contents live.
thumbnail: {
content_type: "image/png", // may be different than the original
url: "some://url/to/the/small/scaled/down/version",
width: 100,
height: 100,
},
preview: {
content_type: "image/png", // may be different than the original
url: "some://url/to/the/larger/scaled/down/version",
width: 1024,
height: 1024,
}
}
* Internally, the URL saved with many of these objects is
"blob://item_id/blob_id" to indicate the item is in our blob store and
the key used to reference it. At API call time, the 'attachments'
controller does some hacks so that all blob:// URLs are converted to a
real URL. If that real URL then winds up with a scheme of "file:///",
we change the URL to be to a new "api/blob" API end-point (otherwise
firefox etc will block the URL). IOW:
- while "blob://" is stored in the database, the consumers of the API
should never see a "blob://" reference.
- If a real blob-store is used, the URL will be directly to that
blob-store (ie, not to our API)
- If a local blob store is used, the URL will be back into our API to an
end-point that will serve the file directly.
* The blob-store currently doesn't know the content-type of the blobs.
Thus, we serve images etc with no content-type header. We need to see
what the real mogile does here.
Let me know how you go...
Mark