Suggestion: Upgrade on cfimage

[Jörn Fischer]

Hi,

I'd like to make a suggestion to the lucee development group to think about a "kind of" upgrade on the cfimage tag.

As we all know cfimage is a pain - regarding file size!
Saving an image (e.g. png) with cfimage will create an image with a  filze larger than the source - in most cases - same dimensions of course!!

On every of our CMS based websites, we get "bad grades" from google page speed on our images - Page Insight tells us: filesize 50+ % to large.
So we decided use optipng to get our PNGs compressed. We integrated the image compressor in our image factory and this decreases the file size - but only for PNGs unfortuneately.

Would there be a possiblity to integration image optimizers like optipng or jpegtran/jepoptim in the new lucee server to get rid of those image file size pains, we all have to live with?

Or has anybody other solutions running? We already tried imageCR3 and imagemagick without success ...

Looking forward to any feedback.

Jörn

[Adam Cameron]

I'd recommend moving this out of Lucee's core CFML implementation, and - from Lucee's perspective - consider it abandonware. I don't think image processing is part of the core language.

Then you could implement your own suggestion (which is a good one, don't get me wrong!).

-- 

Adam

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/e5022d04-ae21-4b2e-890a-5ec88a6c0ac5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Offner]

you are to late with this suggestion ;-)

In Lucee 5 images are already moved to an extension.

Like the search, orm and other stuff as well.

Micha

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAFwR%2BKfarmWWnEOuF62zcQweh7AHGzdLORGrOzSMAiLAnEpi2Q%40mail.gmail.com.

[Simon Hooker]

Whilst I don't particularly make use of <cfimage> I do make use of the cfscript-equivalent fairly heavily in some applications due to the lack of need to install further packages.  Whilst there are better options out there if content/able to use cli tools, I'd not like to see it become abandonware as it at least allows a simple method to do common image manipulations and conversions.

It should definitely be moved out of the core into an extension though, as Micha said is already the case

[Jörn Fischer]

5 days out and yet to late .... f*$% ;-)

Extensions means I may develop one or there are already extension I could use?

But getting back to the point:
Wouldn't it make sense to solve this problem directly from the root instead of spreading the option that everybody gets it's own solution ...?

Jörn

[mail...@gmail.com]

I actually do use the <cfimage> tag to create thumbnails, despite this I agree it is outside the scope of the project and have always just considered it as a wrapper around java image class libraries. That said if there were an opensource alternative that did a better job Id love to get onboard, I have considered using a java image-magic wrapper but have never got round to it.

GX

[Andrew Dixon]

Micha, are you saying that whilst these are moved out of the core to extensions, they will still be extensions that Lucee will provide as standard, maintain and if required develop?

Kind regards,

Andrew

http://about.me/andrew_dixon

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/ed4995cc-adea-44bc-be61-9155b9a8e8b0%40googlegroups.com.

[Adam Cameron]

On 3 February 2015 at 09:31, Simon Hooker <simon....@mso.net> wrote:

Whilst I don't particularly make use of <cfimage> I do make use of the cfscript-equivalent fairly heavily in some applications due to the lack of need to install further packages.  Whilst there are better options out there if content/able to use cli tools, I'd not like to see it become abandonware as it at least allows a simple method to do common image manipulations and conversions.

It should definitely be moved out of the core into an extension though, as Micha said is already the case

I mean abandoned as far as being part of Lucee. Basically park the extension somewhere, and if ppl want to maintain it: cool. But not the Lucee team.

The Lucee team should focus on the language, not the ancillary bells and whistles. There's a community for that stuff.

-- 

Adam

[Stephan]

Sorry to barge in, from a core developer perspective this might make sense, but I think to most web developers image manipulation is a core feature.

It's always been a weak point in CF, and I think if the goal is have Lucee gain wider acceptance offering a more robust implementation out of the box would seem like a better idea.

If the Lucee team will rely on the community for this we'll probably stay at the current point, with some poor solutions or completely outdated/no longer supported ones (imagecr3 for example which works fine most of the time but is no longer being developed with the last version dating back to 2007.)

[Adam Cameron]

Sure. But that's the community's problem, not Lucee's.

This is not directed at you specifically, Stephan, but I've noticed (and yeah, I'm by no measure the first to do so around here) that the "we" pronoun gets bandied around a lot when we WANT something, but not so much when it's suggested we could actually do it ourselves out in general help out. You know: like an actual open source community would usually do.

Lucee do not have a bottomless pool of dev resources. They have to focus on the core language and other stuff the community are less likely to be able to implement. The community has to start putting its hand up more often when there's peripheral work to be done. Especially when it's the community who is asking for it!

But by all means add an enhancement request though. It's not like this is my decision to make!

--
Adam

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Risto]

On Tuesday, February 3, 2015 at 5:27:37 AM UTC-5, Andrew Dixon wrote:

Micha, are you saying that whilst these are moved out of the core to extensions, they will still be extensions that Lucee will provide as standard, maintain and if required develop?

My question too. I'm reserving my opinions as I try to understand Lucee's future vision and path forward. My concern is that "the community" won't support certain extensions like a way to work with spreadsheets or images or whatever. How does it get decided what is core functionality or "core extensions" that are supported by the team? For example, one person might find spreadsheets and image manipulation "bells and whistles" where in my case it's important functionality for the majority of client sites I build and manage. As mentioned, I'm trying to better understand the direction.

[Michael Muller]

As a long-time user of the CFML language and someone who has struggled with image manipulation for a while, switching from cfimage to ImageCR3, to ImageMagik, then back to cfimage, I agree that though this may not be a core-code thing, it's certainly very important as many of us need to deal with images on a regular basis.

I'm not able to participate in writing the level of code as you all do, but I am more than willing to become a paying member / whatever to help support the project, and would hope that someone who knows more than me could come up with a decent and well documented solution that we lesser mortals could use.

There's a reason why I have stuck with the CF language for all these years. It's very simple to use, and forgiving for those who aren't hard-core programmers. I don't want to give the impression that you should hold the language back from being the streamlined, super-efficient model you dream of, possibly attracting coders from other languages, but still... I'm just a scripter at heart. Reading some of the comments here gives me pause.

I guess there's also the step-the-f-up and learn something new point of view, but ... the more you diverge from ACF the harder it will be for people to take that leap.

Anyway, my 2c from the peanut gallery.

Mik

[Mark Drew]

I understand where you are coming from, but this is an open source project that you can use for free. ACF is NOT an open source project. It sells licenses for each and every install of it’s product and is happy to give you support for that product. 

Having to maintain a lot of external functionality in a small group of developers is a pain in the ass  (Micha and Igal, say hello!). So Lucee has an extension model. Where you can create tags and functions and contribute to them so that they match (if you want) ACF’s implementation and not just depend on a small band of developers. 

You can 

a) Pay them to do the functionality you require to do the day job that you get paid for in turn. 

b) Keep up to date with that extension and write tests and contribute to it (a-la Adam Cameron, where he doesn’t contribute code but he makes sure what is there is what SHOULD be there) 

c) Keep saying “I hope someone else wants this extension… *silence*… but it’s important …. *tumble weed*… ACF compatibility! … *groans from the other peanut gallery* “

d) develop the extension for yourself (from existing code perhaps) so that it is doing what you need it to be doing so you keep on getting paid those lovely Megabucks and ALSO contribute to the community. 

e) Know that tickets have priorities and the team might get to if you put a coherent ticket together so that it can be fixed easily without going through the agony of tickets that just say “X doesn’t work”

If you look at Node (io.js) for example, it has… nothing. It has a few bits of API like filesystem and socket listeners. That’s pretty much it. (see http://nodejs.org/api/) but if you want to do image manipulation you can add that with 

npm install gm —save

WOW! A whole GraphicsMagic library for node. Was it in the core? Nop. It has it’s own github repo and own maintainers. 

That is the level that we should get to with Lucee IMHO. 

Sorry for the long post. I am tired of dependency hell and Perl today (ironically) 

MD 

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/40325061-b24d-4b5f-89f9-9291cef2a086%40googlegroups.com.

[Adam Cameron]

On 3 February 2015 at 16:53, Risto <ck.web...@gmail.com> wrote:

 How does it get decided what is core functionality or "core extensions" that are supported by the team? For example, one person might find spreadsheets and image manipulation "bells and whistles" where in my case it's important functionality for the majority of client sites I build and manage. As mentioned, I'm trying to better understand the direction.

To be very clear: "core" is not the same as "important", and conversely "important" does not mean it's "core". 

Taking Sublime Text as an example: I use the CFML and PHP plug-ins for it every day. They are essential to my workflow. However they are not core to Sublime Text, and it would make no sense for them to be so.

Or even ColdFusion Builder. It's not core to Eclipse: it's just a plug-in.

Processing images and PDFs and XLS files is not core to CFML. They might be absolutely mission critical to your application, but that doesn't make them core to CFML (and, accordingly, Lucee).

Also bear in mind no-one's suggesting getting rid of any of this stuff, I'm just suggesting the upkeep and enhancement to them ought not fall within the remit of the Lucee Team. There's nothing to stop anyone else doing whatever they like to these components (same as now).

These are ColdFusion-centric and a bit old now, but describe my perception of what's core and what's not to CFML (The CF implementation of it, anyhow):

http://blog.adamcameron.me/2012/08/coldfusion-modularisation.html

http://blog.adamcameron.me/2012/09/survey-results-coldfusion-modularisation.html

Does that clarify what I mean?

-- 

Adam

[denstar]

On 02/03/2015 10:10 AM, Mark Drew wrote:

[snip great explanation of "we all gotta put food on the table"]

>
> Sorry for the long post. I am tired of dependency hell and Perl today (ironically)
>

LOL! One nice thing about the way I've set things up, is that we can
now do dependencies in CFML.

Instead of having to worry about what is "included" with the engine, one
can easily install the needed dependencies automatically. This is stuff
I've been using for years, and it's just swell-- we'll be getting even
better stuff with Lucee 5, and ForgeBox/CommandBox is doing stuff too...
this is the future.

If the packages are popular, they'll get love (paid or otherwise, tho we
all gotta eat! And if you work for free, and I work for free, who will
buy the beers?!? (a play on the "wash the camels" saying)), that's just
how these things work.

:Den

[Sean Corfield]

On Feb 3, 2015, at 8:57 AM, Michael Muller <mikinm...@gmail.com> wrote:

As a long-time user of the CFML language and someone who has struggled with image manipulation for a while, switching from cfimage to ImageCR3, to ImageMagik, then back to cfimage, I agree that though this may not be a core-code thing, it's certainly very important as many of us need to deal with images on a regular basis.

Agree that this is not a core CFML thing. At World Singles we do all of our image scaling using an external library:

https://github.com/thebuzzmedia/imgscalr

Well, we actually use a Clojure wrapper around it:

https://github.com/josephwilk/image-resizer

We still use the built-in image stuff for a few things but we’ll probably switch that to individual image libraries over time. I notice that Lucee seems to use this project for read EXIF metadata:

https://github.com/drewnoakes/metadata-extractor

One of the issues I filed when we started migrating from Railo to Lucee is that the metadata extracted from an image changed - and now we see less metadata (in particular, some metadata we really need) so we’ll probably switch to something else there. Lucee seems to use 2.4.0-beta-1 of that library - 2.7.2 is the most recent release so we may just try to upgrade first and see what happens :)

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

dev.Objective() - Developing Apps, Developing Skills, Developing Community
-- May 12-15, 2015 - Bloomington, MN - http://devobjective.com

[Risto]

It does. Thanks Adam. I also like the idea of package managers, extensions and such. I also look forward to an even bigger community of extensions and functionality which will probably happen because of this.

Thanks for the links as that was going to be my next question for you:) I agree with you for the most part except a few of your modules that I think should be core.
How many people participated in your Coldfusion Modularisation survey?

What are your thoughts on CFML compatibility between engines? (Maybe I should join your blog and ask there instead)
I ask because this will be a common dilemma for people that actually create,open source or sell CFML applications.

An example could be Slatwall or Mura. If you create a CFML application shouldn't it run on a CFML engine of similar versions? If a CFML app doesn't run on CFML server do you have a right to call it a CFML engine? Are you fine with just saying the requirement is "Lucee only with these extensions installed" even though it's CFML but won't run on other engines? What about people that have invested in ACF and don't want to change? Is the answer to create another version of your app to run specifically on ACF even though your app is CFML? Is the option to lose them as a customer because they won't switch engines?

[ADK]

I get what you're driving at in general and don't disagree, yet I think there's a difference between something that's broken out of the "core" and put into an extension for the sake of modularity (a good thing indeed) and one that's broken out to an extension and then not officially supported by the Lucee team. I don't think those 2 things ought to be lumped together. I'm not trying to imply that you are conflating the two... just that we should probably understand the distinction - where there is one.

Having no interest in ORM whatsoever, I'm thrilled that it's being pulled out of the core and shall not install it, but I'm guessing - and could be completely off - that the Lucee team would be maintaining that rather complex chunk of code? For some silly UI tag, probably not... For someone who heavily depends upon ORM functionality in CFML this distinction would probably be important to determine whether or not they jump to this language/community.

I think that while there's great room for debate on what should be considered "core" or not... I also think that it's valid to question what the Lucee team views as part of their purview? I don't think that's been made abundantly clear yet and so is a valid question.

All of the blog entries and forum posts aside, this language fork rightly so raises a lot of questions in people's minds about the future of this project. This could be a great moment to jump in with 2 feet and help out or just the right push for those on the fence about CFML, and its less than bright future, to invest that energy and time someplace else.

I think that a little clarity from the Lucee team about this future would probably go a long way toward helping some people make this decision.

[Matt Quackenbush]

On Tue, Feb 3, 2015 at 1:16 PM, Risto <ck.web...@gmail.com> wrote:

What are your thoughts on CFML compatibility between engines?

I'm not Adam, of course, but I figured I'd toss my response in the hat for kicks and grins. :-)

Simply stated, I haven't written anything for ACF in at least 5 years, and I plan to never do so again. Anything and everything I write (in CFML) is intended solely for Lucee (and previously, Railo). Why? I'm writing open source software, and I intend for it to be a) used on an open source engine, and b) be supported by the open source community. If a community member(s) decides that (s)he wants to run it on ACF, that's fine with me, and the license will allow that. But it's open source, and therefore the open source community should contribute the parts they need.

Phrased differently, to me it's 100% about the open source ecosystem. :-)

[Sean Corfield]

Caution: this is a bit of a rant / lecture…

On Feb 3, 2015, at 8:57 AM, Michael Muller <mikinm...@gmail.com> wrote:

> I'm just a scripter at heart. Reading some of the comments here gives me pause.

> ...

> I guess there's also the step-the-f-up and learn something new point of view, but ... the more you diverge from ACF the harder it will be for people to take that leap.

Unrelated to image manipulation (and changing the subject to reflect that), but I’ll comment on it anyway: what would you rather have to do… learn some new stuff while still writing CFML in the Lucee world, or find yourself forced to learn a completely new language because CFML "scripter" jobs simply go away as companies move to "real" programming languages that are (perceived to be) more capable?

Yes, many of us have been pushing the "step-the-f-up" p.o.v. for years because part of why companies move away from CFML is the perception that CFML devs are not "real" programmers and are not able to do more than just basic scripting. It’s why, even now, many CFML shops are hiring from outside the CFML pool and cross-training - they can’t find "good" CFML devs.

As a hiring manager, I’m very disappointed with the quality of CFML devs whose résumés I have to plough through and those I interview. A large number still have no experience with / knowledge of:

* version control
* unit testing or TDD
* OOP in any form
* closures or any other functional concepts
* other languages (beyond JS - and that’s often minimal)

Many CFML devs seem to do no tech reading to expand their skills, don’t participate in the online community much, don’t attend conferences. And blaming their employer for that just shows a lack of initiative and desire to improve in my opinion.

So, yeah, I’m not very sympathetic to "scripters" who don’t want to "step-the-f-up" as a hiring manager…

Yes, CFML makes a lot of stuff easy, and it has always allowed untrained folks to build basic apps, but we’re being asked to build more complex stuff these days, and produce code that is more maintainable, more malleable, more robust and so, yes, we all need to "step-the-f-up".

[Adam Cameron]

G'day mate

I can't remember how many participants I got in that survey, but I think it was about 50-odd. So not statistically significant, really.

I'm not sure the best approach to the cross-compat, to be honest. On one hand it'd be nice if a third party project worked on at least the currently supported releases of "all" the engines (well: OK, I just mean Lucee and CF. No-one should care about OpenBD). However at the same time I don't believe in coding to a lowest common denominator either. One thing I have done in the past is to isolate code which leverages platform specific code out into a clearly separate "DMZ" sort of area of my app, and written platform-specific implementations of that code as needs must. "Needs must" is the key here: I'd say if one was a member of the Lucee community and writing an app / module / extension for use on Lucee, I'd code it for Lucee. I'd try to be aware of areas that the CFML might diverge, and not paint myself into any corners, but equally I might not bother writing a ColdFusion-compat version. If someone comes along later and wants a CF-compat version: they can write those bits.

As for CFML language compliance... there's nothing to be compliant with. Adobe never bothered releasing a spec (they are too incoherent in their approach to the language for that, I think), so the best one can do is to keep an eye on what they release when they release it. This is made worse by the fact Adobe don't really do that in return with (formerly) Railo, so we have situations wherein Railo added a feature first, then Adobe has added the same functionality but slightly differently. Jerks. This helps no-one.

TBH Railo had been the innovators in CFML for the coupla years leading up to the fork, and I'd expect Lucee to continue this. Personally I think they should not bother trying to hamstring themselves by staying ColdFusion compatible unless it fits with their own agenda. If people need CF compatibility that Lucee doesn't provide, I wonder if there' scope for people to easily plug replacement function / method / tag implementations in to emulate the diverent behaviour? Perhaps that's something Lucee should strive for, rather than to try to maintain compatibility themselves. Especially if it's at the expense of the direction they want to go.

-- 

Adam

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/a3f505c4-e4a4-469d-b32d-c0753861f192%40googlegroups.com.

[Adam Cameron]

I don't have anything to add, other than agreement with what you say.

Weird. Most unlike me.

-- 

Adam

[Risto]

Love your opinion Matt because I'm just trying to get a feel for what others are thinking.

In regards to your opinon, Mura is an open source CFML application. Shouldn't I be able to use an open source CFML app on a CFML engine regardless of whether I pay for my engine or not? OpenBD is an open source engine as well. So even if I wanted to be 100% in the open open source ecosystem I could use a CFML open source app with an openBD open source engine but possible have to write two different apps one for openBD and one for Lucee. Whew that a lot of "open"

[Adam Cameron]

On 3 February 2015 at 19:31, Sean Corfield <se...@corfield.org> wrote:

Caution: this is a bit of a rant / lecture…

These are my findings too. I don't see as many CVs as I used to (I'm just a grunt these days, not a manager), but you're describing the ones I did used to see.

Interesting though... by the sounds of it it's much the same in the PHP world. There are an awful lot of sub-par developers out there. (Where to be "par" one needs to get on and stay on top of things, know one's craft, and take it seriously enough that one's engagement strays outside 9-5).

-- 

Adam

[Risto]

Got it.

>> OK, I just mean Lucee and CF. No-one should care about OpenBD)

ROTFLMAO!

[Adam Cameron]

On 3 February 2015 at 19:45, Risto <ck.web...@gmail.com> wrote:

In regards to your opinon, Mura is an open source CFML application. Shouldn't I be able to use an open source CFML app on a CFML engine regardless of whether I pay for my engine or not? OpenBD is an open source engine as well. So even if I wanted to be 100% in the open open source ecosystem I could use a CFML open source app with an openBD open source engine but possible have to write two different apps one for openBD and one for Lucee. Whew that a lot of "open"

This is just what we're stuck with thanks to Adobe not handling the language in a sensible and respectful manner, unfortunately.

I would, btw, exclude OpenBD from being considered a CFML engine any more. They gave up on being compatible with anything other than Alan's whim years ago.

-- 

Adam 

[Sean Corfield]

On Feb 3, 2015, at 11:24 AM, Matt Quackenbush <quack...@gmail.com> wrote:

Simply stated, I haven't written anything for ACF in at least 5 years, and I plan to never do so again. Anything and everything I write (in CFML) is intended solely for Lucee (and previously, Railo). Why? I'm writing open source software, and I intend for it to be a) used on an open source engine, and b) be supported by the open source community. If a community member(s) decides that (s)he wants to run it on ACF, that's fine with me, and the license will allow that. But it's open source, and therefore the open source community should contribute the parts they need.

I’m in the same boat. In fact cfmljure 0.1.0 very specifically was NOT ACF compatible and I had no plans to make it so.

Andrew Myers decided to make it compatible and submitted it as a Pull Request. So cfmljure 0.1.1 is ACF compatible (still a pain to interop between ColdFusion and Clojure but that’s ColdFusion’s fault due to how it treats numeric literals!).

I try to keep FW/1 compatible with ACF (since it’s audience is larger) but that’s easier since the CI system I use (on Travis-CI) tests against ACF9.0.2 and ACF10 (thanks to Marcin’s excellent work on cfml-ci!). Again tho’, it’s up to the community to submit PRs for ACF compatibility where CI doesn’t catch something. Currently that CI system uses Railo but I expect to add Lucee at some point, now that cfmlprojects.org hosts the JARs.

Our code at work is Railo-specific - well, Lucee-specific now - and that’s fine. We tested ACF9 against Railo 3.x and decided to go with the latter way back in the prerelease timeframe for ACF9 and we’ve never looked back.

p.s. I look forward to Hibernate being an extension we no longer have to load as part of our system :)

[Matt Quackenbush]

+infinity

I started typing a response but then noticed that Adam typed it for me. :-)