
Imageflow, a 17x faster ImageMagic alternative and more secure - openmaze
http://www.imageflow.io/
======
ck2
Why would you need a web exposed UI?

I guess you could have a local only port to use on a server backend like a
reverse proxy but you definitely don't want this public web facing.

imagemagick is used because it is binary library used on the backend

now if this was a dropin library and command line compatible, adoption would
be 100%

~~~
rollcat
> Why would you need a web exposed UI?

s/UI/API/

That bothers me too, but I can imagine it serves as a nice & complete example
of how to use the library.

> now if this was a dropin library and command line compatible, adoption would
> be 100%

Sometimes fixing a library means you have to break the API... In case the API
sucks and encourages insecure usage patterns. (See LibreSSL.)

Yes it's useful for older projects, but useless and counterproductive for any
new code. Perhaps you could write a compatibility layer on top of the new API?

~~~
ndj7
Imageflow has two parts - libimageflow, and imageflow-server. Both the library
and server offer a JSON API, so it can evolve without breaking changes.

Most users leverage the Dynamic Imaging aspect - you store a single source
file in blob storage, then dynamically generate variants as needed. This is
like Scene7 or Cloudinary, but open-source, and at 1/1,000th of the cost.

------
ndj7
It's clear we can improve our messaging about ways to integrate Imageflow. The
command-line tool aspect is under-emphasized, and the libimageflow aspect
seems to be confusing as well. What other things are unclear initially (or are
still confusing)?

