Make it .net Standard 2.0 / .net Framework 4.8 compatible

[iJungleboy]

I did a quick code review and almost everything is .net standard 2. The only exceptions are:

1. DiskCache - here there was an unused reference - removing that also makes it .net standard 2
2. Imageflow.Server - here there is AFAIK just one file which really is .net core 3.1

So my understanding is, that with fairly small changes this could also run on .net 4.8 - which would make it useful for DNN (DotNetNuke) and probably other CMSs and .net solutions. I believe we would need to...

1. Set DiskCache to compile as .net Standard 2
2. Move most of ImageFlow.Server to the Helpers OR move the 2-3 things that really compile with .net core 3.1 into an own project
3. Create another tiny project Imageflow.Server which reuses almost all the code, and mainly recreates ImageflowMiddleware.cs in a .net standard 2.0 or a .net Framework 4.8 code. I assume we could reuse some of the ImageResizer code

So my question is - could you (or we) do this? I believe it would help many people - including us (who create 2sxc, the most used DNN extension).

If you do it - what would we need to sponsor?

If we do it, would you incorporate it into your code, so there is only one standard code base?

[lilith]

Are you trying to run this on ASP.NET 4? There's quite a bit different about middleware between that and ASP.NET Core.

I wouldn't be against incorporating another project into the codebase that targets that, but I think there would be a lot of code duplication or exposure. I don't really (yet) want to make internal details from Imageflow.Server public to enable re-use across projects.

I don't think the internals have baked long enough to become an interface.

I do plan on adding an Imageflow backend to ImageResizer in the future, once I've gotten Imageflow.NET Server refined to my satisfaction. Would that address your needs better?

[iJungleboy]

Thanks for the quick response ;)

So I think all options are similar in value to us. Basically ImageResizer is fairly old (and robust - so that's a plus) and some of the goodies in Imageflow would be highly appreciated in our use case (DNN/2sxc). One of the main ones on the short term are better Webp support (I also started a few issues around that), but basically having ImageFlow on .net 4.x would be very important to us (the DNN Community).

Whether that happens by making it the engine inside ImageResizer or making the middleware as described here is basically equivalent to us. So yes, that would be awesome.

[dgroh]

@iJungleboy I think for that use case you can achieve using imageflow-dotnet and implement it in you DNN Architecture? You would have the DNN Api which calls a .netstandard service layer which contains the logic of handling the image. The only thing you would have to do on your own would be the caching strategy with DiskCache or something else in DNN.

I can't quite get why you would want to integrate a Imageflow-Server into DNN, but I would be interested in knowing more.

If you don't want to setup a server and don't want to use the imageflow-dotnet you can contribute here and try to bring the DNN Imagehandler to a next level: https://github.com/dnnsoftware/Dnn.Platform/issues/3910

I would also be interested to know what speaks against of you setting up the imageflow-server outside the DNN instance? For me those are two different things. I wouldn't integrated something which is supposed to be a server into a CMS system.

[lilith]

We've separated out Imazen.DiskCache for this reason, so that it can be used by .net standard libraries to implement their own pipeline. The following features would need to be copy/pasted or re-implemented though:

• Watermark support
• S3 and Azure Blob storage support
• Presets
• Command defaults
• Cache Control
• Cache invalidation when presets, defaults, or watermark configuration changes
• Authorization

[iJungleboy]

Just back from vacation...

@dgroh We're the creators of 2sxc http://github.com/2sic/2sxc/, the most used CMS extension for DNN (as DNN isn't really a CMS at all). It includes ImageResizer.net as part of the solution, so that content-editors can just add images and everything else just magically happens - without special training for the users etc.

Since it's a install-and-go extension, doing anything on another server would make it extremely difficult to install for the users, and almost impossible to distribute. So it has to be in DNN to fly. Our implementation of ImageResizer.net https://github.com/2sic/dnn-imazen-imageresizer has been working very well for this for many years.

We've never included it as part of the standard DNN distribution (even though I'm in the DNN core group & MVP) because of various reasons incl. keeping DNN very slim and also licensing issues which get extra complicated once it's in the base package.

Now we want to update it to the latest Tech, incl. WebP support. What's also an issue is SVG to JGP/PNG conversion, which neither ImageResizer nor ImageFlow can do yet, but if it's ever added it will be in ImageFlow of course.

@lilith What do you think would be the best way forward?

1. Create an own .net classic / 4.8 wrapper for ImageFlow
2. attach ImageFlow to ImageResizer?

And what's your plan in general for .net classic?

[lilith]

You need a base version that is Apache 2 licensed, correct? If so, we should stick with ImageResizer and add an optional Imageflow backend.

[lilith]

Closing this for now, please feel free to reopen if you have additional feedback. I do plan to add an Imageflow backend to ImageResizer. Only ImageResizer has an Apache 2 backend - Imageflow is AGPL/Commercial.

[iJungleboy]

Hi @lilith

I would like to pick up on this again. Basically our goal is to get ImageFlow to run on .net classic (4.8) with WebP support and everything. It's ok if it will be AGPL licensed (which was the main cause we closed this last time) as we want to include it with 2sxc which is also open-source, and mention this aspect during installation.

What would be the best way to get this to run? I assume there are 2 main options

1. Implement a http-handler in .net 4.8 which calls imageflow-dotnet-server, similar to the .net core wrapper
2. Implement a connection layer between the existing image-resizer which offloads all the work to imageflow-dotnet-server

Questions:

1. Which one of these do you think would be feasible / preferable?
2. Or is there a better (maybe already existing alternative) that I'm missing?
3. Is this somewhere on your roadmap or is there some easy way we could jump in and help (or sponsor) the work?

Many thanks, Daniel

PS: @tvatavuk and I created an integration for ImageFlow and Oqtane (a new Blazor based .net platform). You can find it here: https://github.com/2sic/oqtane-imageflow

[lilith]

ImageResizer is unwieldy to work on. The build scripts are in 2014-era F# and no longer function, everything is designed for VS2017 tooling, and there are so many settings and compatibility bridges and patches for various content management systems that a real overhaul would break lots of integrations. We're slowly fixing this but it's a big task. Movement on ImageResizer is just too slow.

You could probably create a focused alternative based on Imageflow.Server code in a few days since all the hard code is in .NET Standard 2.0. I would skip supporting Imazen.DiskCache and only support Imazen.HybridCache and Imazen.Common. This will make your async HttpModule code extremely simple.

The trickiest bits to pay attention to when porting are probably cache invalidation, watermark configuration, and request signing. Also whether you want to support plugins or not - do you use/support blob storage?

[lilith]

oqtane-imageflow looks great! Send a PR for the readme and I can link to it.

Regarding your other two questions, (2) I'm not aware of a better alternative. Nothing does real-time image compression as good as Imageflow. Windows-only WIC-based approaches might be faster now that Windows has upped their codec game, but the file sizes are nauseatingly large. (3) This isn't on the roadmap except as part of ImageResizer. Most of our customers rely on specific features and settings in ImageResizer, so we have to slowly bring ImageResizer into the future without making breaking changes. This could take a very long time. I don't see a sufficiently large number of people willing to suffer breaking changes unless they're also upgrading to .NET Core 3.1/5. CMS plugins like 2sxc where it's all abstracted are probably the exception.

[iJungleboy]

1. I just created the PR with the readme update
2. Thanks for the guidance - we'll see if it looks feasible in terms of resources
3. We don't use blob-storage, so that wouldn't be a priority as of now.

[lilith]

Hi @iJungleboy, I've finally made a significant chunk of progress on ImageResizer v5 and have a working Imageflow backend. Would you be up for helping me keep up momentum on this and bouncing some ideas around?

[iJungleboy]

Hi @lilith

As of ca. May 2022 we have successfully replaced ImageResizer in DNN with ImageFlow, as we assumed ImageResizer is EOL.

It's implemented as an HTTP Module - the code is here: https://github.com/2sic/dnn-imageflow

I believe we won't need the integration to ImageResizer anymore, but maybe I'm missing something?

[lilith]

Oh, I'm glad to hear you have a solution!

I will take a look. What are you using for the disk cache?

On Mon, Aug 8, 2022, 2:58 AM iJungleboy @.***> wrote:

Hi @lilith https://github.com/lilith

As of ca. May 2022 we have successfully replaced ImageResizer in DNN with ImageFlow, as we assumed ImageResizer is EOL.

It's implemented as an HTTP Module - the code is here: https://github.com/2sic/dnn-imageflow

I believe we won't need the integration to ImageResizer anymore, but maybe I'm missing something?

— Reply to this email directly, view it on GitHub https://github.com/imazen/imageflow-dotnet-server/issues/6#issuecomment-1207854362, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA2LHZXWJMVHJZ5V6BNVJ3VYDD45ANCNFSM4OEMWD6A . You are receiving this because you were mentioned.Message ID: @.***>

[iJungleboy]

Not sure - @tvatavuk?

[tvatavuk]

Hi @lilith and @iJungleboy, it is using Imazen.HybridCache nuget based on code in https://github.com/imazen/imageflow-dotnet-server. You can look at https://github.com/2sic/dnn-imageflow/blob/main/Cache/HybridCacheService.cs.

[lilith]

@tvatavuk @iJungleboy Awesome! It's looking good.

ImageResizer was EOL, but I had a breakthrough to (hopefully) bring it back. I'm thinking I may be able to create a new .NET Standard lib to unify lots of the codebase with Imageflow.Server (and maybe with dnn-imageflow as well, if that's interesting).

I am thinking that all the events around URL rewriting and authorization could benefit from standardization so that such customizations can easily be ported back and forth. I'd also like to enhance the file serving support for things like byte ranges and caching features beyond ETags, so a shared codebase would benefit from that.

If you upgrade Imazen.Common and HybridCache to yesterday's version, there's a breaking change in the interface to no longer use a Tuple, but rather a IStreamCacheInput instance.

[lilith]

ImageResizer 5 is shipping soon with Imageflow support: https://github.com/imazen/resizer

[iJungleboy]

Hi @lilith

Could you describe briefly (or document somewhere) how this could/should be used?

To me it's not clear if we should "return" to ImageResizer + ImageFlow or if using ImageFlow directly is the way to go.