Suggestion: Upgrade on cfimage

dev google-group-archive
1

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 http://optipng.sourceforge.net/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

2

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

On 3 February 2015 at 08:26, Jörn Fischer <@Jorn_Fischer> wrote:

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 http://optipng.sourceforge.net/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

–
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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/e5022d04-ae21-4b2e-890a-5ec88a6c0ac5%40googlegroups.com
https://groups.google.com/d/msgid/lucee/e5022d04-ae21-4b2e-890a-5ec88a6c0ac5%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

3

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.)On Tuesday, February 3, 2015 at 5:48:51 AM UTC-5, Adam Cameron wrote:

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

Whilst I don’t particularly make use of 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

4

5 days out and yet to late … f*$% :wink:

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

5

Got it.

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

6

I actually do use the 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.

GXOn Tuesday, February 3, 2015 at 10:29:10 AM UTC+2, Adam Cameron wrote:

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

On 3 February 2015 at 08:26, Jörn Fischer <joern…@onebyte.ch <javascript:>> wrote:

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 http://optipng.sourceforge.net/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

–
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 <javascript:>.
To post to this group, send email to lu...@googlegroups.com <javascript:>
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/e5022d04-ae21-4b2e-890a-5ec88a6c0ac5%40googlegroups.com
https://groups.google.com/d/msgid/lucee/e5022d04-ae21-4b2e-890a-5ec88a6c0ac5%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

7

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. :slight_smile:

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. :-)On Tue, Feb 3, 2015 at 1:16 PM, Risto <@Risto> wrote:

8

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?

9

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

+infinity

I started typing a response but then noticed that Adam typed it for me. :-)On Tue, Feb 3, 2015 at 1:51 PM, Adam Cameron <@Adam_Cameron1> wrote:

On 3 February 2015 at 19:45, Risto <@Risto> wrote:

10

[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.

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

11

Whilst I don’t particularly make use of 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.On 3 February 2015 at 09:31, Simon Hooker <@Simon_Hooker> wrote:

–
Adam

12

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 <https://github.com/thebuzzmedia/imgscalr>

Well, we actually use a Clojure wrapper around it:

https://github.com/josephwilk/image-resizer <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 <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 :slight_smile:

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.comOn Feb 3, 2015, at 8:57 AM, Michael Muller <@Michael_Muller> 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.

13

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_dixonOn 3 February 2015 at 09:57, <@mailme.gx> wrote:

I actually do use the 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

On Tuesday, February 3, 2015 at 10:29:10 AM UTC+2, Adam Cameron wrote:

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

On 3 February 2015 at 08:26, Jörn Fischer joern....@onebyte.ch wrote:

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 http://optipng.sourceforge.net/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

–
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
https://groups.google.com/d/msgid/lucee/e5022d04-ae21-4b2e-890a-5ec88a6c0ac5%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

–
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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/ed4995cc-adea-44bc-be61-9155b9a8e8b0%40googlegroups.com
https://groups.google.com/d/msgid/lucee/ed4995cc-adea-44bc-be61-9155b9a8e8b0%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

14

you are to late with this suggestion :wink:
In Lucee 5 images are already moved to an extension.
Like the search, orm and other stuff as well.

MichaOn Tue, Feb 3, 2015 at 9:29 AM, Adam Cameron <@Adam_Cameron1> wrote:

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

On 3 February 2015 at 08:26, Jörn Fischer <@Jorn_Fischer> wrote:

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 http://optipng.sourceforge.net/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

–
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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/e5022d04-ae21-4b2e-890a-5ec88a6c0ac5%40googlegroups.com
https://groups.google.com/d/msgid/lucee/e5022d04-ae21-4b2e-890a-5ec88a6c0ac5%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

–
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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAFwR%2BKfarmWWnEOuF62zcQweh7AHGzdLORGrOzSMAiLAnEpi2Q%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAFwR%2BKfarmWWnEOuF62zcQweh7AHGzdLORGrOzSMAiLAnEpi2Q%40mail.gmail.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

15

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

16

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 http://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 :slight_smile:

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.comOn Feb 3, 2015, at 11:24 AM, Matt Quackenbush <@Matt_Quackenbush> 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.

17

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

On 3 February 2015 at 19:16, Risto <@Risto> wrote:

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?

–
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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/a3f505c4-e4a4-469d-b32d-c0753861f192%40googlegroups.com
https://groups.google.com/d/msgid/lucee/a3f505c4-e4a4-469d-b32d-c0753861f192%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

18

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.On 3 February 2015 at 19:45, Risto <@Risto> wrote:

–
Adam