Store x/y coordinates for crops

[kirkbushell]

There's a few good reasons for this - the main one is that if you want to curate your images when they're requested, rather than creating new files on creation, you can do that.

Secondly, this allows curations to be used across services - such as imgix.

I think it would be great if curator distanced itself from image management and instead wrote adapters that managed this. That way, we could still use curator for all the heavy lifting in the admin, but leave the implementation and management of the curations to our own implementations.

A really good issue I found when using curator is that if for some reason your files aren't exactly stored close (let's say I'm working locally but have an s3 bucket in Europe (a world away)), list views which are doing file checks for each record, slow down the page loads immensely. That issue aside, I'm still not sure why it does this - it's perfectly okay to serve 404 responses for images rather than doing checks.

[awcodes]

I can agree with your 1st and 2nd points.

For the third point, I feel that you might be leaning to much on curations and missing the point of the plugin. Granted Curator's mindset and methodology is different from what we have become accustomed to as developers, I feel it's better than creating multiple images at multiple sizes for every image that's uploaded. The curations are only meant to be for one off focal point corrections. If you need dynamic image sizes that's all possible currently using the getSignedUrl method on the model. This will go through glide and generate what you need.

For your 4th point I would need more details. Those checks have been put in place over time to fix bugs with external disks.

[awcodes]

And if you're using something like imagix or Cloudinary. You'd be better off extending the media model and overriding the url attributes to return the images directly from those services so they don't waste time going through glide.