News for hackers. Stuff that matters.
Re:Shrine – A new solution for handling file uploads in Ruby by anonova on Tuesday October 27, 2015 @06:49PM (#10461745)
The creator of carrierwave started the new project refile [1] as a better alternative. Is there a comparison between the two approaches, i.e, refile vs shrine?

[1]: https://github.com/refile/refile

Re:Shrine – A new solution for handling file uploads in Ruby by janko-m on Tuesday October 27, 2015 @07:25PM (#10461903)
I was actually contributing actively to Refile before, so in a lot of ways Shrine is similar to Refile (the idea of backends is basically the same). However, the main difference is that Refile does processing on-the-fly, while Shrine (and CarrierWave) do it upfront, so it goes in that direction. Basically in Shrine I added all of the features I was missing and wanted to change, which I wasn't able to add to Refile in a compatible way. One major addition is the support for background jobs, which I just couldn't see how it could be added to Refile. Also, I wanted Shrine to be far less opinionated than Refile, that you can have much more options how to do uploads.
Re:Shrine – A new solution for handling file uploads in Ruby by jrochkind1 on Tuesday October 27, 2015 @09:04PM (#10462295)
Can you explain what you mean by "upfront" vs "on-the-fly"? I'm somehow not getting it.

This looks very nice. It'll need lots of docs with examples to understand how to put together the nicely flexible building blocks you provide.

Re:Shrine – A new solution for handling file uploads in Ruby by janko-m on Tuesday October 27, 2015 @09:48PM (#10462423)
"Upfront" processing means that you're doing the processing during upload, and on the "on-the-fly" processing means that you first upload the file, and then it's processed dynamically through the URL. For example, in Refile you make an URL to the uploaded file like this:

/attachments/sdkd/resize/300/300

That will make Refile trigger the specified processing at the moment the URL is requested. You should then put a CDN or a reverse proxy in front to kind of cache these processed files, so that they're not processed each time.

About the documentation, I wrote documentation for each of the plugins, and I linked them all on http://shrinerb.com. The plugin names should hopefully indicate what feature they accomplish, and since they're all individual, it's up to the user to choose what features they want (i.e. combination of plugins).

Re:Shrine – A new solution for handling file uploads in Ruby by jrochkind1 on Wednesday October 28, 2015 @09:40AM (#10464331)
So "up front" still includes doing the processing in a background job async, as long as it's triggered at point of upload, not at point of request?

"upfront" but async background does seem to be the best way to approach it to me, at least if you had to pick one -- that's what Shrine does?

Re:Shrine – A new solution for handling file uploads in Ruby by janko-m on Wednesday October 28, 2015 @04:16PM (#10467080)
Yes, you got it right, this is exactly what it means. Yeah, there are some rare use cases for on-the-fly processing (think a WYSIWYG editor where the user can choose the size of the image), but for me upfront definitely works best.
Re:Shrine – A new solution for handling file uploads in Ruby by jrochkind1 on Wednesday October 28, 2015 @04:25PM (#10467133)
Cool. I'd call those two choices "upon upload" (instead of 'upfront'), and "upon first view" (instead of "on the fly"), but I'm sure my terminology would confuse someone else too.
Re:Shrine – A new solution for handling file uploads in Ruby by _neil on Tuesday October 27, 2015 @07:22PM (#10461894)
I'd also be interested in a brief comparison. This is the first I've heard of both Shrine and Refile. I'm really excited that backgrounding and direct uploads are being simplified in both projects.