Should we rename the primary module names for 1.0? about image_processing HOT 3 CLOSED

Good thoughts! The way I think about this is:
Is ImageProcessing always going to have a single middle dependency on the underlying processor i.e. Vips and ImageMagick or will it be open to supporting multiple middle libraries that wrap Vips and ImageMagick?

If this gem will always depend on a single wrapper library then I'd go with the more accurate module names. If this gem might depend on multiple wrapper libraries, then I'd use the wrapper libraries for naming.

This applies more for MiniMagick and RMagick (and maybe some FutureMagick :) ) especially if there are trade-offs in supported functionalities/performance between the wrapper libraries and we may want to support all of them.

My 2 cents.

from image_processing.

Or maybe Vips is an informal name used within the libvips community? But, even so, the official project name and branding (what little there is) use the libvips name.

The project was original named "VIPS", you can see it in the Wikipedia page (btw, it's interesting to see how long history it had 😃). Until recently the official website was http://vips.ecs.soton.ac.uk, where the official name was displayed also as "VIPS"; the website has since been moved to http://jcupitt.github.io/libvips/.

I think that the project is still called "VIPS", but it was just centralized into the libvips library, as that's the single place that contains all the processing code, so that's why I think it's more common to reference libvips directly. But I think we can still call it "vips", as the name libvips originated from "vips". On the other hand, for ImageMagick the repository is named the same – "ImageMagick" – though the libraries like "MagickCore" and "MagickWand" do drop the "Image" part.

ImageProcessing::MiniMagick is, of course, named after the minimagick gem. But that seems like an implementation detail. The main point of this module is to interface with imagemagick.

Yes, but as @hmistry said, I think it's important to communicate this implementation detail. When RMagick was revived a few years ago, I knew that I wanted to leave the doors open for ImageProcessing::RMagick to be implemented. MiniMagick being just a CLI wrapper has it's cons, so I could see ImageProcessing supporting both MiniMagick and RMagick, and then people can choose which one they prefer.

Also note that ImageProcessing delegates all unknown methods to the ImageMagick CLI builder, and an RMagick::Image object could respond to different methods than the options available in the CLI. So it's not technically an implementation detail, because you map directly to CLI options (an RMagick::Image object might respond to different methods). And you can also interact directly with the MiniMagick::Tool object via the #custom block.

Now, regarding the ImageProcessing::LibVips suggestion, I would prefer to stick with ImageProcessing::Vips, because ruby-vips is the official Ruby gem with libvips bindings, and unlike with Minimagick/RMagick I don't see any possibility of another implementation arising. Also I would feel a bit strange naming it ImageProcessing:::RubyVips, so I decided for just Vips.

from image_processing.

You both make very good points, @janko-m and @hmistry. Totally makes sense.

I'm glad to know there are solid motivations for their current naming scheme and that's inherently flexible for the future.

Thanks for listening to my crazy idea! 👍

from image_processing.