4.0 draft spec

Config changes

• src_dir is the dir where the path is looked for. For me, this is typically public_path().'/uploads'. But, this could potentially be app_path().'/storage/assets' or a Flysystem instance bound to the IoC container.
• crop_dir is where crops are created. For me, this is typically public_path.'/uploads' as well. But, it could be public_path.'/uploads' or a Flysystem instance bound to the IoC container.
• path is a regex pattern or a callable that matches the path to the asset relative to the crop dirs. The introduction of this config deprecates the old public and ignore params.

Class re-organization

• ServiceProvider - Listen for requests that match the Croppa regex. When found, hand off to Handler.
• Handler - Coordinate the rest of the classes.
• Url - Appends and parses params of URLs
• Image - Apply crops / transformations to src images in memory
• Storage - Read images into memory for transformations and save them back. Also, contain functions for cleanup, like deleting all crops.
• Facade - Expose easy methods for generating Urls and tags.

Examples

Current

• Asset : /public/uploads/bar.jpg
• Request : http://domain.com/uploads/bar-200x100.jpg
• src_dir : /public/uploads
• crop_dir : /public/uploads
• path : ^uploads/(.*)$ (starts with "/uploads" and then the path)
• $path : bar-200x100.jpg

The path matches the request. The path from the request can be appended to the src_dir to find the asset. A crop is created and stored in the crop_dir at the requested path. On the next request, apache can server that crop directly.

Src is different than crop dir but both local

This is the case of #36

• Asset : /storage/12/15/bar.jpg
• Request : http://domain.com/assets/12/15/bar-200x100.jpg
• src_dir : /storage
• crop_dir : /public/assets
• path : ^assets/(.*)$
• $path : 12/15/bar-200x100.jpg

Works the same as previous example.

Remote src, local crop dir

A load-balanced scenario described in #52 where the crops are created on each app server but there is a canonical location for the srcs, like S3 or a NAS.

• Asset : https://whatever.s3.amazonaws.com/uploads/bar.jpg
• Request : http://domain.com/uploads/bar-200x100.jpg
• src_dir : upchuck.disk An IoC-bound Flysystem instance whose bucket is whatever and whose prefix is uploads/
• crop_dir : /public/uploads
• path : ^uploads/(.*)$
• $path : bar-200x100.jpg

Croppa will check the src_dir using app()->bound('upchuck.disk') to see if the src_dir string matches a bound instance. It will then return that instance and validate that it is_a League\Flysystem\Flysystem instance (or a League\Flysystem\Cached\CachedAdapter). Assuming it is, it will check if the file exists using ->has() and, if it does, will use it as the source for the crop, creating it locally like normal. On subsequent requests, it gets served directly by Croppa.

Remote src, Remote crop dir

A Heroku-style scenario described in #52 like where you can't keep any crops or uploaded images on the app server.

• Asset : https://whatever.s3.amazonaws.com/uploads/bar.jpg
• Request : http://domain.com/uploads/bar-200x100.jpg
• src_dir : upchuck.disk
• crop_dir : upchuck.disk
• path : ^uploads/(.*)$
• $path : bar-200x100.jpg

Finding the source works as described above. But on crop create, the crop is created back on the remote disk. On future requests, Croppa will notice that the crop_dir is a Flysystem instance and use it's API to check whether the requested crop actually exists. If it does, it will 301 redirect to it. The reason this doesn't have to be painfully slow is that Flysystem's cache feature will prevent subsequent lookups to the remote disk. You still have to boot up the whole app on each image request but their isn't a network request involved. Still, this is not ideal. It would be better to sit Cloudfront in front of this so that they handle subsequent requests.

--

• Should I use Flysystem for all my own operations, even locally? In other words, if they're not using a Flysystem bound container for one of the *_dirs, should I instantiate one just to do local operations? I'm leaning towards this so there is only one Disk I/O API.
• Do I want to get into updating image handling library #30 ?