Developer documentation

[James Kilford]

I'm writing to canvass your opinions on the developer documentation for Railo Server.  

I'm just starting to write the documentation for Railo and I'd value your input on what should go into it (or be left out of it).  At this point, I'd like to sketch out the "table of contents", in its entirety, and then fill in the detail afterwards, rather than start writing haphazardly.

You can see my ideas for the documentation on Railo's github: 

https://github.com/getrailo/railo/wiki/Documentation-structure

Please let me know if you have any ideas or comments. 

The biggest section is likely to be "Developing applications with Railo Server"... and I'd really like to find out how you think this should go.  Are you interested in: 

* sample apps

* tutorials

* design patterns

* explanation of all Railo Server's language features

* enhancing Railo Server

* editors / IDEs

* integrating Railo Server with other products, e.g. search engines, message queues

* something else?

Let me know what else you'd like to see in this section... All opinions welcome!

On the other hand, perhaps you think it should be very lightweight and that people should use ACF documentation in general, with Railo Server documentation covering the Railo-Server-specific matters only.  

Many thanks, 

James

[Igal Sapir]

+2 for the initiative!

--
typos, misspels, and other weird words brought to you courtesy of my mobile device and its auto-(in)correct feature.

--
Need help right now? Why not have one of the Railo Team help you directly: http://www.getrailo.com/index.cfm/consulting/
---
You received this message because you are subscribed to the Google Groups "Railo" group.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Billy Cravens]

Go deep on the admin. I'd make it a stand alone chapter, as I think the subject is more than a subtopic under "Manage Railo Server apps". As a matter of fact, the very structure of the admin (Server/Web) speaks to the idea that there's app-specific admins, and server-wide. I think this is the biggest area of confusion for most developers coming from ACF.

Detailed section on various installation methods:

- local Express version

- installer

- WAR deployment

- JAR deployment

This needs some detailed explanation as you get some subtle differences in directory structure and behavior based on the method. As this is mostly a Java deployment concern, and not necessarily specific to Railo in many cases, maybe some some background on how Java deployment works would build a nice foundation for understanding. 

Tangential to installation is installation of external libraries (such as MongoDB or AWS SDK). Based on installation method, it can be a bit tricky identifying where specifically to place external JAR files.

I wouldn't tackle sample apps, design patterns, specific external integrations, etc. I think the surface area for that sort of thing is far too great.

The focus should be on ACF devs coming to Railo, rather than newbies to CFML. That seems the more likely scenario.

Billy Cravens
bdcr...@gmail.com

[Mark Drew]

I would disagree with just ACF -> railo. We have a lot of new users that I don't want to say "go look at ACF". 

Regards

Mark Drew

Sent from a mobile device

[James Kilford]

Thanks Billy, appreciate the feedback.  I've updated the ToC.  Couldn't agree more with the web / server admins.  That was an area that vexed me at first when I started using Railo Server.  

Like you, I thought that most people coming to Railo Server would be previous ACF users.  However, I understand that's not the case, so I'm thinking some of that stuff might be useful.  It would be great if we can let people know that Railo Server can do all the stuff that their [insert favourite language here] can do.  So, I've added a section for comparisons with other languages and CF servers.

As for the sample apps, perhaps I was over-egging the pudding there.  Maybe "exemplar code" would be a better way of helping people along -- templates / CFCs that are a reflection of the current best practices say?

Many thanks, 

James

[Cameron Childress]

On Fri, Mar 22, 2013 at 11:33 AM, James Kilford <nkil...@gmail.com> wrote:

Like you, I thought that most people coming to Railo Server would be previous ACF users.  However, I understand that's not the case

I would not point to the ACF docs in lieu of writing Railo documentation, but I do think that pointing out the differences between Railo and ACF (where they exist) is helpful and important. This could be done inline as a callout box, or all at once in a predictable location (foot of page?). This could be done within the context of version differences between Railo editions as well.

I assume this will be written as a Github Wiki in the long term? It would be fantastic to have the ability to edit/contribute to the docs as needed. One of the weak points of ACF's docs are that, even though it has a commenting mechanism, corrections made in the comments rarely make their way into the actual body of the documentation content.

-Cameron 

--
Cameron Childress
--
p:   678.637.5072

im: cameroncf

facebook | twitter | google+

[Jean Moniatte]

Hello,

Nice, thanks for your efforts!

I think that it would be helpful to have generic "How Tos", for loops, http calls, ftp sessions etc... For example loops are much better in Railo yet it is difficult to find information about them. I am not sure how such articles would fit into your structure.

As well, a tag/function reference by category? I find it super useful in the ACF docs.

Thanks again,

Jean

--

Jean Moniatte

UGAL

je...@ugal.com

http://www.ugal.com

[Matt Quackenbush]

+1 to Cameron's thoughts.

Also, a HUGE THANK YOU for the initiative!

[Billy Cravens]

I didn't so much mean to point to ACF docs and punt on general usage, but rather, I'd focus on the unique aspects of Railo first. This makes the docs usable sooner rather than later, as I feel the mass majority of folks reading it would have little use for a general CFML tutorial. After you've finished the Railo specific pieces, then move on to general CFML. (in other words, I'm commenting more on the when than the what)

Billy Cravens
bdcr...@gmail.com

[Mark Drew]

ONe of the projects I like to use for a lot of the "what is this CFML language and how does it work" are from the CFML in a 100 minutes by Mike Henke:

https://github.com/mhenke/CFML-in-100-minutes

Then I think there are the CFML Koans if you want to look at best practice:

http://bittersweetryan.github.com/ColdFusion-Koans/

Both are under the Creative Commons attribution license, so we can get them into the documentation and modify as we see fit to get that area filled out. 

There is a bunch of herding of the existing documentation that can be done into this structure. The "differences of railo" to me, make no sense in a way. You should learn Railo and work with that. At least that is what I want the documentation to be. 

With regards of differences between Railo x.y and ACF x.y I think it's a fools errand and would help a few people for a short time compared to using James' time more wisely. 

So you know, we have hired James to do this work, hence I would prefer it to be a bit focused. 

Sincerely

Mark Drew

The Railo Company
Professional Open Source
skype: mark_railo ma...@getrailo.com
+44 7971 852296 http://www.getrailo.com

[Jean Moniatte]

+1 to the constant comparison with ACF. I agree that it should be avoided.

And thanks to Railo for putting resources behind the documentation project!

Jean

--

Jean Moniatte

UGAL

je...@ugal.com

http://www.ugal.com

[Billy Cravens]

The fact that he's writing the documentation for Railo, supporting the company's goals, certainly shifts perspective. I suppose it all depends on the goal of the docs. Is it to help those already using the language? Is it to provide an on-ramp for those choosing Railo vis-a-vis Python, Ruby, etc? Is it to provide a comprehensive source for those that write CFML apps in many engines? 

I know as I look at different languages or APIs or whatnot for projects, I quickly look for a "Documentation" link and whatever I find behind that link tells me a lot about the viability of the product. In many ways documentation becomes a marketing tool (even open source projects market themselves)

Billy Cravens
bdcr...@gmail.com

[Billy Cravens]

Wholehearted agreement on the kudos for Railo getting behind the documentation.

As to constant comparison to ACF, that sounds good, but when ACF 11's feature set is announced, let's see if none of those new features are implemented shortly in Railo. :-) Then there's the marketing materials ("Railo CFML is free, so you can spend your money on building your applications, not buying costly server licenses." "Railo has good compatibility with other CFML engines.") I think those comparisons are great, and correct, and appropriate. Certainly, while ACF isn't referenced by name, it's implicit. What was the last function or tag implemented uniquely by OpenBD that found it's way into Railo? Again, no problem, it makes sense to stay in lock step with ACF given market share in the CFML space. But let's not act as if that's not happening, or have a disconnect between the marketing and developer relations side of things.

That said, let me apologize: my intention wasn't to hijack the thread. I was simply trying to relate how I feel documentation would best serve developers needing it, and from my view (CF since 1999, CFUG manager (technically "sponsored" by Adobe,) and someone who develops in many languages) I see most developers that use Railo going ACF -> Railo.

Billy Cravens
bdcr...@gmail.com

[Mark Drew]

The fact that he's writing the documentation for Railo, supporting the company's goals, certainly shifts perspective.

How so? We are investing in someone to provide documentation for the project. 

I suppose it all depends on the goal of the docs.

Is it to help those already using the language? 

Of course

Is it to provide an on-ramp for those choosing Railo vis-a-vis Python, Ruby, etc? 

I think the goal is to get people using Railo effectively. Whether you have just started out or have some experience already. Our project is NOT the same as others and we need to document how it works, not simply how it differs. 

Is it to provide a comprehensive source for those that write CFML apps in many engines? 

Not sure why we would be writing this? how is this of benefit to Railo Server or The Railo Company? (I mean this from an amount of effort point of view) 

I know as I look at different languages or APIs or whatnot for projects, I quickly look for a "Documentation" link and whatever I find behind that link tells me a lot about the viability of the product. In many ways documentation becomes a marketing tool (even open source projects market themselves)

You are right and hence this has been a bug bear for a long time that I for one have spent a lot of my time on and now we are hopefully getting James on board to help us create better documentation for our project. 

In the end I would like the documentation to support Dan. Dan is a student that has just left Leeds University and wants to create the next awesome web site. He will learn the language, be able to deploy it, become a better developer even though he already knows some Java and some C++ from his courses. 

I want the documentation to help Halbert. He has been developing applications for years, day in, day out in Boring Co. and knows five tags but wants to stop "working for the man" and do his own thing, he wants to get better at his coding to make stuff work. 

I want it to be good for Sandra, who has AWESOME design skills uses LESS and SASS to make front ends that you would die for and knows that by using some languages that are similar to her own she can kick ass. She doesn't want to write her own damn server with node.js

I want it to be good for Delray. He is an über developer of glory at his company and wants his servers to fly. He is a coding GOD and the company has even hired a junior developer to JUST get Delray coffee. He knows his interfaces from his WSDL, he knows his extends and his MVC and makes Sean Corfield look like a nincompoop. But dammit, why are there two admins? 

Make sense?

MD 

P.S. all these people are fictional… and if they seem like people we know? They might not be at all. 

[Cameron Childress]

On Fri, Mar 22, 2013 at 12:42 PM, Mark Drew <ma...@getrailo.com> wrote:

With regards of differences between Railo x.y and ACF x.y I think it's a fools errand and would help a few people for a short time compared to using James' time more wisely. 

As someone who has clients on ACF 7, 9, and 10 as well as clients on Railo, I would find documentation of the differences to be extraordinarily valuable. However, I recognize that I may not represent all or even most of Railo's developer base.

If spending time on calling out such differences is not a high priority right now, that's fair. But people are likely to keep asking for it so perhaps these sorts of things would fall under "community responsibility" for the docs. Assuming these are going to be an editable Wiki format, it would be great for the Railo team to define a documentation framework for this sort of activity to be contained within in the docs. 

Call it "The Railo Documentation Manifesto" - a mission statement and clear roadmap for documentation contributors to follow. Map out what the Railo team is going to do themselves and give an A, B, C of what volunteers can do and how to do it so that the docs don't get messy.

While we're on ideas for special content callouts...  There is a pretty good bit of blog content out there around examples and usage of the CFML language and Railo. How about a section on each page (or a link to a companion page for each) that lists "related reading" or "supplemental reading". It may be a challenge to vet the links, but linking to Brian Kotek's ORM blog series or John Wish's ORM book would be FAN-FRACKING-TASTIC to find right there as a callout in the ORM section. You could pretty much index Ray Camden and Ben Nadel's blogs against the entire doc set too if they didn't mind, which they might...

Also - along with others - huge thanks for these efforts!

-Cameron 

[James Kilford]

Yes, I agree with you about looking at the "Documentation".  Going to JQuery or Knockout or whatever and looking at the documentation gives me an idea of where we could get to.  The problem, as Mark has demonstrated is that all developers -- new-to-CFML or crossover -- will have a different view of what the documentation must do.  

It's daunting to start when there's a blank page, but I'm hopeful that if we get the skeleton in place, and start filling it in, it will be easier for others to contribute.  If anyone has a spare half-hour to knock up a quick page about something that interests them, it all helps in the end.  

[Tom Miller]

I agree with Cameron,

 

The thing I need the most is the differences. For instance, I’m sure I heard somewhere that Railo now supports group on cfloop and nested cfloops. When I tried to look, it took me about 20 mins to find it, when really, a google search for “Railo cfloop” should have been all I needed to do.

 

I’m probably just lazy, but it’s handy that a google search for a cf tag always brings the ACF documentation for that tag to the top of the google search results.

 

I’m sure with enough inbound links it’d get there eventually…

--

[James Kilford]

On 22 March 2013 18:03, Cameron Childress <came...@gmail.com> wrote:

On Fri, Mar 22, 2013 at 12:42 PM, Mark Drew <ma...@getrailo.com> wrote:

With regards of differences between Railo x.y and ACF x.y I think it's a fools errand and would help a few people for a short time compared to using James' time more wisely. 

As someone who has clients on ACF 7, 9, and 10 as well as clients on Railo, I would find documentation of the differences to be extraordinarily valuable. However, I recognize that I may not represent all or even most of Railo's developer base.

Yes, I'd like that sort of documentation too, not least because I think it would give people the confidence to turn to Railo Server and not look back.   

 

If spending time on calling out such differences is not a high priority right now, that's fair. But people are likely to keep asking for it so perhaps these sorts of things would fall under "community responsibility" for the docs. Assuming these are going to be an editable Wiki format, it would be great for the Railo team to define a documentation framework for this sort of activity to be contained within in the docs. 

Call it "The Railo Documentation Manifesto" - a mission statement and clear roadmap for documentation contributors to follow. Map out what the Railo team is going to do themselves and give an A, B, C of what volunteers can do and how to do it so that the docs don't get messy.

Yep, I think that, in documentation, structure is key.  I'm really keen to draw up the theoretical perfect documentation ToC and then attack it! 

 

While we're on ideas for special content callouts...  There is a pretty good bit of blog content out there around examples and usage of the CFML language and Railo. How about a section on each page (or a link to a companion page for each) that lists "related reading" or "supplemental reading". It may be a challenge to vet the links, but linking to Brian Kotek's ORM blog series or John Wish's ORM book would be FAN-FRACKING-TASTIC to find right there as a callout in the ORM section. You could pretty much index Ray Camden and Ben Nadel's blogs against the entire doc set too if they didn't mind, which they might...

I like this idea a lot.  I'd pencilled in "Useful resources and further reading", but of course in-line links would be terrific.  It wouldn't be too difficult to produce some sort of verification tool in the long term.  

James

[Igal @ getRailo.org]

so if you have a "personal" site (by personal I mean, a site that is yours and not a client's) an inbound link would be greatly appreciated ;)

[Tom Miller]

Happy to :)

 

Maybe a “powered by railo” widget people can just copy and paste in their footers would be good. I see there’s an “unofficial” logo here, but a code snippet would be nice too

http://www.getrailo.org/index.cfm/community/spread-the-word/

 

Tom.

 

 

 

From: ra...@googlegroups.com [mailto:ra...@googlegroups.com] On Behalf Of Igal @ getRailo.org
Sent: 22 March 2013 14:15
To: ra...@googlegroups.com
Subject: Re: [railo] Developer documentation

 

so if you have a "personal" site (by personal I mean, a site that is yours and not a client's) an inbound link would be greatly appreciated ;)

On 3/22/2013 11:10 AM, Tom Miller wrote:

I’m sure with enough inbound links it’d get there eventually…

 

--

[Igal @ getRailo.org]

+1

we should definitely update these "buttons" (especially the ones that have 3.1 in them).

[Cameron Childress]

On Fri, Mar 22, 2013 at 2:14 PM, James Kilford <nkil...@gmail.com> wrote:

I like this idea a lot.  I'd pencilled in "Useful resources and further reading", but of course in-line links would be terrific.  It wouldn't be too difficult to produce some sort of verification tool in the long term.  

Validating that the link returns 200 is a good start, but I think the bigger challenge will be validating the the content in the blog post is accurate and worth linking to, especially since the link would be coming from the "Official Railo Documentation".

So, while I don't think this responsibility belongs directly in the lap of the official documentation team, it's worth defining a mechanism to prevent junk links to bad info.

-Cameron

 

[Denny]

On 3/22/13 12:31 PM, Cameron Childress wrote:
...

> So, while I don't think this responsibility belongs directly in the lap of
> the official documentation team, it's worth defining a mechanism to prevent
> junk links to bad info.

We should probably follow the StackOverflow model, and pull the relevant
content in.

As for the "engine differences" docs, I'm planning on putting something
like that on cfmlprojects.org, which is for community CFML stuff vs.
Railo specific stuff.

The compatibility matrix can be pulled from the CFML dictionary files,
which kills a couple birds with one stone-- they're also used by the
project builder to flag incompatibilities when you change the target
engine (or engine version). Not saying anybody shouldn't do whatever
they'd like -- document away! -- just that there's a place for things
that are outside the scope of Railo-centric docs.

:Denny

--
Railo Technologies: getrailo.com Professional Open Source
Skype: valliantster (505)510.1336 de...@getrailo.com
GnuPG-FP: DDEB 16E1 EF43 DCFD 0AEE 5CD0 964B B7B0 1C22 CB62

[AJ Mercer]

I agree with Mark on this.

You don't have to write everything your self; I have see quite a few Wikis will have links to other resources, like blog posts. So maybe put out an invite to people that have come from other areas to Blog their experiences and thoughts and compile a list of those. This way you don't fill up the documentation that is only relevant to a small percentage of readers.

I like the structure you have so far. Thanks for getting behind this project.

AJ Mercer
<webonix:net strength="Industrial" /> | <webonix:org community="Open" />
http://twitter.com/webonix

Railo Community Manager

[Nick Kwiatkowski]

I've been moving most of our CF8 and CF9 servers at my office to Railo.

The biggest things we ran into were installation related.  Detailed instructions on how to install for use with IIS, How to get SSL to work, how to get BlazeDS to work, how to get multi-domains to work on a single site (and multi-site in general).  Most of these tasks are pretty easy if you know where to look (and are used to Tomcat).  

Also, having better documentation for those converting applications FROM ACF to Railo would be a huge plus.  I knew that CFAUTHENTICATE was a no-go, but things like not having support for SFTP tripped me up.  Also, better documentation on some of the features that work different/better than ACF like the S3 support, caching support, etc.  Most of the search engine results / blog posts about how to do those things go to the old wiki -- so they are broken links.  

-Nick

[Mark Drew]

I really think that documentation about moving from X to Railo should be done by the community. 

You guys are having the experience and should document that and add it to the wiki. 

—
Sent from Mailbox for iPhone

--

[Risto]

I just want to chime in on a "differences between ACF and Railo" being most valuable to me too.  I'm not getting rid of ACF anytime soon
since many clients I do work for already have it in place.  So why is that important if I want to develop an app on Railo? It probably isn't, but
if I'm creating a CMS or other software I would be a fool not to try and make it compatible with both engines, and a nice guide of the differences would be golden.

[Mark Drew]

Then share your knowledge in the wiki. 

The funding we are putting forward is to produce documentation for our product. As has been asked. Conversion guides would be from the community. 

—
Sent from Mailbox for iPhone

[Risto]

Of course we will have to if that's our only option, but it's also important for the Railo team to understand that your user base does think that a "differences between ACF and Railo" is important.

[Mark Drew]

We understand this but you are a vocal

minority. 

Look, go have a look at the framework one documentation. It has information on what it does and how you do it. It doesn't have information on how to use fw/1 if you use model glue. 

There are political and practical implications to that kind of documentation. I am paying someone to write documentation. I want to get the basics covered. 

I am sure all switchers will contribute to any documentation and advice on using railo anyway. 

Regards

Mark Drew

Sent from a mobile device

On 24 Mar 2013, at 16:33, Risto <ck.web...@gmail.com> wrote:

Of course we will have to if that's our only option, but it's also important for the Railo team to understand that your user base does think that a "differences between ACF and Railo" is important.

[Christian Ready]

Let me chirp in here and say that Railo doesn't exist to help users migrate away from ACF, nor does it seek to (another company positioned their product to help business migrate from CF to .NET - oddly enough they weren't warmly embraced by the CF community).

True, both are CFML language runtime compilers and yes, each vendor has an interest in maintaining compatibility with the other to a large extent. But it's also true that they have their own reasons for doing certain things a little differently.

To frame the request another way, should Adobe provide the public with documentation on the differences between ACF and Railo? They could and they certainly have the financial resources to do so, but I personally don't think they have any obligation to do so, and if they chose to take on such an endeavor, they would probably spend a lot of time and money keeping their documentation current and accurate.

My $0.02

--

Christian Ready

The Railo Company, Ltd

Professional Open Source

skype: christianready chri...@getrailo.com

+1 410 382 8070 http://www.getrailo.com

[Matt Quackenbush]

I've really tried hard to (mostly) stay out of this thread because I don't want to stir up any pot. But I just can't stay quiet any longer.

First off, Christian has hit the ball out of the park with his reply. Kudos to him for framing the biggest issues with the whole "differences between X and Y" thought process so well.

Secondly, as an open source author (and contributor, but especially as an author), I could not possibly care less if my *open source* project runs on a closed source, commercial engine. When I made the decision to switch from the engine I had been using since ~1995, I did so for many, many reasons, but chief amongst those reasons was FREEDOM. Part of that freedom is not caring about the differences between Railo and anything else. I believe in and support Railo, and all I care about is: How does Railo work?

Lastly, when Railo first began, it was likely important to discuss differences between it and other engines. However, the days of Railo being a start-up, infantile, fledgling product attempting to find its footing are long gone. Railo has been the driving force behind the development of the language for 2-3 years now. It is - in my opinion - way, way, way, way past time for Railo to care about differences. Railo is Railo. Other engines are other engines. Railo's market (from my perspective) is not the same as that of the other engines' authors, and time spent on the other engine's markets is completely wasted.

Long Live Railo!

[Mark Drew]

Sure. I get it. 

So write it already. 

—
Sent from Mailbox for iPhone

On Sun, Mar 24, 2013 at 4:33 PM, Risto <ck.web...@gmail.com> wrote:

Of course we will have to if that's our only option, but it's also important for the Railo team to understand that your user base does think that a "differences between ACF and Railo" is important.

[Adam Cameron]

On Monday, 25 March 2013 09:02:22 UTC+13, Mark Drew wrote:

We understand this but you are a vocal

minority. 

Really? From a position of not having any stats to demonstrate anything one way or another, this really surprises me. I would have thought the bulk of Railo users would be people migrating from ColdFusion, not people entirely new to CFML. I'm not disagreeing with you, Mark, but that you suggesting otherwise really surprises me.

 

Look, go have a look at the framework one documentation. It has information on what it does and how you do it. It doesn't have information on how to use fw/1 if you use model glue. 

From my understanding and from what I see in the community, this is not a like-for-like comparison. Everyone I know who uses Railo is coming from ColdFusion, and so "differences between ~" docs would be the most important. At the end of the day, all the "same as ~" docs are already written by Adobe, so at least until you get funding (or volunteers donating time) to document everything, the initial best quick win would seem to be to cover the differences.

 

There are political and practical implications to that kind of documentation.

Are there? Ones that are really significant in the bigger scheme of things? And more important than getting Railo documented in the most useful (for the community) fashion?

 

I am paying someone to write documentation. I want to get the basics covered. 

You should be targeting what's going to be most beneficial to most people. I'm not saying you're not doing that. But that's the approach you should have.

--
Adam

[Risto]

Wow, maybe I missed the whole point of the thread. I applaud everyone who has ever contributed to any Railo documentation. I also agree that you should get the basics covered if you are paying. I also think some missed my point. The Railo team knows what and who it wants to focus on, and that's great too. No, ACF doesn't publish a guide on the differences between ACF and Railo, and I wouldn't if I was ACF. My point is if there was a "differences guide" it would ease newcomers doubt switching from ACF to Railo because they could look up tags and functions they are concerned about.

I thought converting ACF users to Railo was really important. If so, then a "differences guide" would be most helpful. I don't care what other projects write or document, my opinion was focused
on Railo. You've already made your point clear, the community needs to write it.

[Justin Carter]

Like it or not, there are politics involved. Anyone in the community can publish a "differences" guide, but Railo don't necessarily want to publish a "here's how to migrate away from ACF" guide because it could be taken the wrong way. 

Like Mark says, it's community developers who will have the most experience doing this anyway. And from my experience, following a "guide" won't help you find all the edge cases in your code - you basically need to test your code on Railo and see what breaks, then fix it. No amount of reading compatibility tables or guide can do this part for you unfortunately.

[Adam Cameron]

Really? From a position of not having any stats to demonstrate anything one way or another, this really surprises me. I would have thought the bulk of Railo users would be people migrating from ColdFusion, not people entirely new to CFML. I'm not disagreeing with you, Mark, but that you suggesting otherwise really surprises me.

I figured there's one way to find out. I've a quick survey here:
http://adamcameroncoldfusion.blogspot.co.uk/2013/03/how-did-you-come-to-be-using-railo.html

--
Adam

[Adam Cameron]

On 25 March 2013 14:50, Justin Carter <justin....@gmail.com> wrote:

Like it or not, there are politics involved. Anyone in the community can publish a "differences" guide, but Railo don't necessarily want to publish a "here's how to migrate away from ACF" guide because it could be taken the wrong way. 

Well which way would it be taken that was the "wrong way"?  Railo wants to improve its penetration, and the best place to get new bums on seats is from already-established CFML users. It's going to me much easier to do that than to acquire people who have never used CFML before.  Let's face it: Railo is primarily "and alternative to ColdFusion", not something in and of itself. Sorry, but it's not.

And Adobe won't care if Railo does this. I don't think Adobe thinks Railo is of any real consequence to its bigger scheme of things (this could change in coming years, but I mean "at the moment"). I can't see that there's a litigation risk here (and litigation is the only thing that matters in the context of "taking things the wrong way"), because in what way would Adobe benefit? They will be savvy enough to see that litigating against a poor little OSS project is going to do them more PR harm that it would financial good.

 

Like Mark says, it's community developers who will have the most experience doing this anyway. And from my experience, following a "guide" won't help you find all the edge cases in your code - you basically need to test your code on Railo and see what breaks, then fix it. No amount of reading compatibility tables or guide can do this part for you unfortunately.

I think that's a bit naive.  Other than it being free (which is going to be its biggest "selling" point), Railo had to differentiate itself from ColdFusion. Railo has to a) convince me to use it at all; b) identify how much work it will be to convert from ColdFusion. And both of those types of information will be most easily extracted from a "differences between Railo and ColdFusion" guide.

Not only will most of Railo's incoming (from ColdFusion) community members find this documentation the most useful, it'll also going to be a useful marketing tool.

Mark can bang on saying "well you community guys write it then", but he's being a bit naive too IMO. Most people using open source software use it because it's free, not because they can contribute to it. And, indeed, as contributing takes time, and time is money, actually contributing to a project is actually counter to why they want to use it in the first place (the "it's free" bit). Railo: it's your software, you should be doing your best to promote it and to ease people into it. This is not the job of the community IMO anyhow. And I think the crossover docs would be the best use of documentation effort, to start with.

--
Adam

[Mark Drew]

I also read all the download feedback ;)

—
Sent from Mailbox for iPhone

--

[Mark Drew]

Thank you for your opinions Adam. 

I am not naive and I am basing my opinions on facts that I see in a wider sense than just this community. Both as statistics and talking people that are downloading and using our software for one as well as talking to or clients. 

I have made note of your marketing suggestions and of course with an unlimited budget and infinite resources we could do everything at once. But this is not the case. 

By the way there already is documentation on compatibility here:

http://www.getrailo.org/index.cfm/documentation/compatibility/

If that needs to be expanded, I can move it to the wiki and you guys can either send us additions and changes or do it for yourselves. 

James asked for your feedback and we got it. Thank you. 

—
Sent from Mailbox for iPhone

--

[Adam Cameron]

On Monday, 25 March 2013 20:23:00 UTC+13, Mark Drew wrote:

I also read all the download feedback ;)

Oh of course. Like I said, I was surprised, not that I didn't believe you. And I also just presumed you had a basis for what you said, rather than pulling it out of yer arse ;-)

Still: it'll be interesting to see what comes out in this survey (not that it'll be statistically sound).

--
Adam

[Mark Drew]

I try not to pull stuff out of my arse. 

I also see a the reasons people put for joining this group and also I am in charge of the training as well as some areas of marketing Railo as a product and as a company. 

I get to see a bit wider than just the open source community. 

—
Sent from Mailbox for iPhone

--

[Denny]

On 3/24/13 9:01 PM, Adam Cameron wrote:
...

> being a bit naive too IMO. Most people using open source software use it
> because it's free, not because they can contribute to it. And, indeed, as
> contributing takes time, and time is money, actually contributing to a
> project is actually counter to why they want to use it in the first place

> (the "it's free" bit). Railo: it's *your* software, you should be doing

Statistically speaking you might be right about open source software and
"most" people -- depending on how you divvy things up -- but an attitude
like this isn't doing much to help that, if so. =]

Personally I love being able to contribute. It feels empowering. A
nobody-to-blame-but-myself type of freedom. Sure I might have to learn
some language I've never used before to work on software X, but I can do
it. Or pay someone (*anyone*) to do it. One of /many/ reasons why open
source software is the bee's knees.

I like to think that most people would contribute if they could.

Time is not really money (have you seen "The Price of Life"? Read the
short story "Time is Money"? :]), or else it's not a transitive
property, because kids would be the wealthiest and most powerful if it
were... Pooling resources is no joke though, regardless of how you see
space-time. Thank you for your contributions!

I'm fine with your opinion, although I don't agree, and I'm super-fine
with the data you shared detailing CFML's list and array functions, and
the differences between engines, and within the language itself. Gold!

> your best to promote it and to ease people into it. This is not the job of
> the community IMO anyhow. And I think the crossover docs would be the best
> use of documentation effort, to start with.

Surely you can't be /that/ surprised to learn new people are coming to
the language?

Why should the focus on promotion and easing in, be on crossing over?

I feel like you want someone to say CFML is Dead. :)

[David]

Hi James,

Some feedback and opinions:

-In your TOC I don't see why you have a section on "free" and much later on a section on "open source".  They are linked.  Also, being open source brings with it the 4 freedoms, which I have always found to be a powerful message. 

-I would prefer that the documentation going forward is not separated by Railo version, but that there are notes telling when it was introduced.

-It would be nice if people could easily post corrections and clarifications alongside each section or feature.

-Having the full documentation rather than just the differences between ACF would be awesome. 

-It would be nice to be able to download the documentation as a PDF.

-You have some broad background sections.  Perhaps for those you could be a cat-herder and get others to create a first draft or provide links so that you are just editing and compiling the general stuff and putting most of your attention on developer documentation.

Good luck and thank you.  This will be a very nice resource.

David

[James Kilford]

Thanks David, appreciate the feedback.

-In your TOC I don't see why you have a section on "free" and much later on a section on "open source".  They are linked.  Also, being open source brings with it the 4 freedoms, which I have always found to be a powerful message. 

That layout started as a stream of conciousness, so the order isn't quite finished.  I put a lot of "notes to self" in there...  I'll move things around a bit and add your comments. 

-I would prefer that the documentation going forward is not separated by Railo version, but that there are notes telling when it was introduced.

We were talking about this morning -- some of it should just evolve over time, and some of it will have to be updated with each version.  But I think the tag stuff, for example, should be available for different versions.

-It would be nice if people could easily post corrections and clarifications alongside each section or feature.

Definitely.  We want to keep the wiki format so that people can dive in as they wish.  

 

-Having the full documentation rather than just the differences between ACF would be awesome. 

Definitely.

 

-It would be nice to be able to download the documentation as a PDF.

Couldn't agree more!  Using the wiki, in a suitable wiki format, i.e. Markdown, as a source document means that we can convert it to PDFs or ebooks.   

 

-You have some broad background sections.  Perhaps for those you could be a cat-herder and get others to create a first draft or provide links so that you are just editing and compiling the general stuff and putting most of your attention on developer documentation.

Yep.  This is definitely as much about curation as it is about writing.  There is actually a load of documentation already written, but it's maybe not that easy to find it.  

 

Good luck and thank you.  This will be a very nice resource.

I'm hoping that this effort will create something which will be easy for people to dive in and amend / add to.  Please feel free to add other sections / make suggestions.  

James

[Billy Cravens]

Re documenting multiple versions of Railo, what versions are "supported"? Once that question is answered, I'd limit documenting differences to only those.

Billy Cravens
bdcr...@gmail.com

[Mark Drew]

As I mentioned on your blog post, your reach with this survey will just give you skewed results. EVERYONE will be coming from one CFML engine or another! 

I need to run the numbers again, but for our downloads we get between 30-40% of people that are new to CFML (last count a while back but since I read them as they come in, that is the current feeling)

Sincerely

Mark Drew

The Railo Company
Professional Open Source
skype: mark_railo ma...@getrailo.com
+44 7971 852296 http://www.getrailo.com

[Adam Cameron]

G'day Mark:
Yes, the results will definitely be skewed to only report on people who a) participate on the various forums I posted this to; b) are inclined to participate in surveys. However I don't think the extension of your logic is sound in that "EVERYONE will be coming form one CFML engine or another". Are there no people on this list who entered the CFML community via using Railo? I hope you're not right on that count. Or if so, it mitigates the skewing somewhat.

Do you have any metrics of people who hit the Railo download page, but don't fill in that form? What are those numbers like?

It's good that you're getting that 30-40% though. That's very encouraging. Hopefully a bunch of those people are participating here too!

Cheers for thinking about this, Mark.

--
Adam

[Mark Drew]

Answers inline. 

On 25 Mar 2013, at 20:31, Adam Cameron <adamcamero...@gmail.com> wrote:

G'day Mark:
Yes, the results will definitely be skewed to only report on people who a) participate on the various forums I posted this to; b) are inclined to participate in surveys. However I don't think the extension of your logic is sound in that "EVERYONE will be coming form one CFML engine or another". Are there no people on this list who entered the CFML community via using Railo? I hope you're not right on that count. Or if so, it mitigates the skewing somewhat.

Well, also a lot of people will download Railo and NOT become part of the community (i.e. sign up to the google group) at all. 

Do you have any metrics of people who hit the Railo download page, but don't fill in that form? What are those numbers like?

Not at present, I mean, we have them, we just need to clean them up (double downloads, bots etc etc)  which I don;t know. I wouldn't be able to tell you what they were thinking but we have roughly 4-5K downloads a month. 

It's good that you're getting that 30-40% though. That's very encouraging. Hopefully a bunch of those people are participating here too!

Hopefully! 

Cheers for thinking about this, Mark.

Most welcome!

[Billy Cravens]

How do you count those who do not fill out the form? 

I've probably hit the download page maybe 100 times or more, and I'm pretty sure I've never filled it out.

Billy Cravens
bdcr...@gmail.com

[Mark Drew]

We try to de-dupe by duplicate IP address and time range. 

Not the best way I know, but hey, it helps a bit. 

Sincerely

Mark Drew

The Railo Company
Professional Open Source
skype: mark_railo ma...@getrailo.com
+44 7971 852296 http://www.getrailo.com

[Adam Cameron]

Me too. Well: not 100 times, but a coupla dozen. From different machines/IPs etc, so will all count as discrete downloads.

It's important info because it represents the margin of error in any stats gathered. So the 30-40% Mark mentioned before loses a lot of significance if they can't balance that out with those that don't fill the form in at all.

At a guess, most people wouldn't fill out the form? But just a guess.

--
Adam

[Mark Drew]

Unless we ask for a login before downloading I am not sure what we can do Adam. 

And no, we are not doing that. 

Regards

Mark Drew

Sent from a mobile device

[Ron Stewart]

I've worked my way through this thread and something I don't see discussed here is the tag and function reference material. In my opinion, that documentation is essential to all of the example Railo users that MD touches on in his follow-up and it also very relevant to MD's and others' comments about whether or not the Railo documentation is intended to be standalone or deal with the differences between Railo and other CFML engines. It is some of the most basic developer documentation for the tool.

I'm glad to see that it does appear in the outline on the wiki, but I'm going to make a plea for significant improvements to the quality of at least the current tag reference and possibly the function reference material. 

I'm in the process right now of updating the CFML editor mode I maintain to provide Railo 4-specific tag- and tag attribute-completion, so I've recently spent a fair amount of time wading around in the tag reference content within the Railo Admin. In the past three days, I have looked at every page of the tag reference at least once. The quality and completeness of that documentation varies widely from tag to tag and even for attributes within a given tag. If I were new to CFML (I'm not), there is no way that documentation would be sufficient. There are tags with no or nearly no documentation, and there are numerous tags with key attributes with nearly no meaningful documentation. Because I haven't spent as much time in the function reference, I don't have a corresponding picture of whether it suffers some of the same gaps. 

As someone coming to Railo from another CFML engine, I see some value in having some documentation of the differences between Railo and other CFML engines. For me, though, the proof is in the pudding: I'm porting a couple of our apps to it and very quickly finding out where there are differences in the language and in the configuration that are relevant to these apps (and therefore to me).

For someone trying to get a comprehensive picture of certain aspects of the language syntax or as someone new to CFML or Railo, a comprehensive high quality reference would be particularly valuable. 

For specific representative examples of areas where the current tag reference is incomplete, see any of the following (and I have list of quite a few more):

- tag cfadmin

- tag cfmap

- tag cfmapitem

- tag cfqueryparam and cfprocparam's respective cfsqltype attributes

- tag cffunction's access and returnformat attributes

- tag cffile and cfftp's respective action attributes

My two cents: decent developer documentation has to include (if not start with) a decent language reference. It is the one part of the Adobe ColdFusion documentation I find myself continuing to use on a semi-regular basis, either directly or through something like cfquickdocs.com. Even Ray Camden alluded to an aspect of this in a tweet today about trying to remember, after more than 10 years of using the language, the order of the arguments to function FindNoCase().

(And for the record, I have a love/hate relationship with the built-in reference in the Railo Admin: I love having it there and think it's a great idea, I love that it is also programmatically available via function calls, and continually find myself frustrated by the content itself.)

On Thursday, March 21, 2013 11:53:09 AM UTC-6, James wrote:

I'm writing to canvass your opinions on the developer documentation for Railo Server.  

I'm just starting to write the documentation for Railo and I'd value your input on what should go into it (or be left out of it).  At this point, I'd like to sketch out the "table of contents", in its entirety, and then fill in the detail afterwards, rather than start writing haphazardly.

You can see my ideas for the documentation on Railo's github: 

https://github.com/getrailo/railo/wiki/Documentation-structure

Please let me know if you have any ideas or comments. 

The biggest section is likely to be "Developing applications with Railo Server"... and I'd really like to find out how you think this should go.  Are you interested in: 

* sample apps

* tutorials

* design patterns

* explanation of all Railo Server's language features

* enhancing Railo Server

* editors / IDEs

* integrating Railo Server with other products, e.g. search engines, message queues

* something else?

Let me know what else you'd like to see in this section... All opinions welcome!

On the other hand, perhaps you think it should be very lightweight and that people should use ACF documentation in general, with Railo Server documentation covering the Railo-Server-specific matters only.  

Many thanks, 

James

[James Kilford]

Thanks Ron, appreciate the feedback.  

The tag and function documentation IS being looked at by Railo anyway, though my focus is on the other parts of the documentation.  

James

--

[Michael Offner]

this is the function and tag documentation (also used by the compiler to parse the cfml source code)

https://github.com/getrailo/railo/blob/4.0/railo-java/railo-core/src/resource/fld/web-cfmfunctionlibrary_1_0

https://github.com/getrailo/railo/blob/4.0/railo-java/railo-core/src/resource/tld/web-cfmtaglibrary_1_0

everybody is free to change texts here and send a pull request.

Micha

2013/3/26 James Kilford <nkil...@gmail.com>

--

/micha

Michael Offner CTO Railo Technologies GmbH

[Adam Cameron]

Hi Mark!
I wasn't suggesting altering the way you gather the data, it was more that you need to bear in mind those "no answer" results when analysing said data (and I'm not even suggesting you're not doing that, I'm just chatting here). EG: is that 30-40% you mentioned "30-40% of all downloads", or "30-40% of people filling out the form"? Those are two different metrics. Also if like only 1% of people didn't fill in the form, the figures you do have have more "certainty" than if say 99% of people don't fill in the form. One could possibly extrapolate that the 30-40% would carry across the "no answers" too, I s'pose. Or in the bigger scheme of things it simply might not be that important one way or the other.

Depending on what info is more important to you, perhaps pushing the name / email address bit down further, asking for the usage metrics first? Speaking for myself, I will never provide my name and email address if I don't have to, fearing spam (and I simply don't want to ever hear again from whoever's website I am on, generally). But I will give metric info like the other questions quite freely because I know it can help them, and is no "cost" for me. Obviously this is only me, so I cannot speak to how other people approach forms.

--
Adam

[Matt Quackenbush]

It's not often I can rubber stamp a comment from Adam, so when I can I must. :-)

On Tue, Mar 26, 2013 at 2:38 PM, Adam Cameron wrote:

Depending on what info is more important to you, perhaps pushing the name / email address bit down further, asking for the usage metrics first? Speaking for myself, I will never provide my name and email address if I don't have to, fearing spam (and I simply don't want to ever hear again from whoever's website I am on, generally). But I will give metric info like the other questions quite freely because I know it can help them, and is no "cost" for me. Obviously this is only me, so I cannot speak to how other people approach forms.

+infinity

[Adam Cameron]

It's happening all too often, Matt! I can't be antagonised by you if you agree with me (well: actually I can probably find a way, knowing me... ;-)

--
Adam

[Bilal]

Gents

I want to get back to James initial question. And add a few suggestions:

a) I applaud the effort. Whatever form it takes it is an improvement.

b) I would not underestimate the need for a complete tag reference with basic examples. This seems placed into your TOC inline in the Developing Apps area. I do believe it probably warrants its own large section/manual organized by tag function area. I would suggest that the Script elements are also mentioned within each tag reference entry. If you script it, how + example.

c) If the Cloud is the future, it needs a larger coherent place in App Docs, : How to design an app for the cloud, manage it, what are coding considerations, what does file system really mean, etc. The sample app showing off how to scale Railo cluster on Amazon? A control panel that can brings up instances, shows loads, session in cluster?

d) If I were in a new developer's shoes I would want to find out what I can build with this thing based on that I would decide whether I wanted to learn any more. This is what Joomla and Wordpress did for Php; they catapulted php into dev awareness. So, time spent on a solid  developer sample apps that show the power of the language and eco-system, is, in my opinion, time well spent.

For example, Microsoft uses the AdventureWorks concept in many of its dev tools to highlight features and creating attractive sample apps. Could a similar concept app exist for Railo? Maybe a sample Pinterest type site, allowing people to pin images, videos, blogs: rate and comment? A sample webstore? Walk route app? (scenic walks, ratings, comments, maps) + mobile 4 square comments? 

Mobile integration to any sample app? Chat?

Just my 2.

Best,

Bilal

[James Kilford]

Hi Bilal, 

On 27 March 2013 15:21, Bilal <bilal...@gmail.com> wrote:

Gents

I want to get back to James initial question. And add a few suggestions:

a) I applaud the effort. Whatever form it takes it is an improvement.

b) I would not underestimate the need for a complete tag reference with basic examples. This seems placed into your TOC inline in the Developing Apps area. I do believe it probably warrants its own large section/manual organized by tag function area. I would suggest that the Script elements are also mentioned within each tag reference entry. If you script it, how + example.

Yes, I agree.  This is something that Railo is working on.  My focus is the other stuff at the moment.  The Developing Apps area is just a bit random for the moment, while I get feedback and ideas and organise it.   

c) If the Cloud is the future, it needs a larger coherent place in App Docs, : How to design an app for the cloud, manage it, what are coding considerations, what does file system really mean, etc. The sample app showing off how to scale Railo cluster on Amazon? A control panel that can brings up instances, shows loads, session in cluster?

That would be an awesome piece of work, though I suppose not everyone wants to deploy to the cloud.  I'm hopeful that we can get input from the community at large to help with developing documents like that one -- or perhaps it could be a distillation of discussions in this group.  There's loads of useful discussions that could feed into the documentation. 

 

d) If I were in a new developer's shoes I would want to find out what I can build with this thing based on that I would decide whether I wanted to learn any more. This is what Joomla and Wordpress did for Php; they catapulted php into dev awareness. So, time spent on a solid  developer sample apps that show the power of the language and eco-system, is, in my opinion, time well spent.

Yeah, I like this idea, but again I think it's a formidable job to produce, and then document the production of, sample applications -- especially if they're going to be decent apps.  Perhaps an easier goal would be to produce code samples to demonstrate particular points or concepts. 

 

For example, Microsoft uses the AdventureWorks concept in many of its dev tools to highlight features and creating attractive sample apps. Could a similar concept app exist for Railo? Maybe a sample Pinterest type site, allowing people to pin images, videos, blogs: rate and comment? A sample webstore? Walk route app? (scenic walks, ratings, comments, maps) + mobile 4 square comments? 

Mobile integration to any sample app? Chat?

Just my 2.

Best,

Bilal

Really appreciate all the feedback.  I've updated the contents accordingly.  

James

[Mark Drew]

We did an application for video sharing for the book. Maybe that application to go into this?. Otherwise we also did a task manager application for the book which can also be suitable candidate?

—
Sent from Mailbox for iPhone

--

[Nick Kwiatkowski]

Mark,

One of the things that Railo could help us more with is the slight differences in tags, implementation, etc that even those of us who have gone through migrations before might be unaware of.  Not necessarily a complete "migration guide", but things that may not be uncovered until you use it. 

For example, I found myself struggling with the lack of SFTP support within the CFFTP tag.  The docs didn't really mention it on the Railo side, and the only other thing to turn to would be the ACF docs... I think having some of those things highlighted as different from the "standard" would be really useful for those of us who are targeting both platforms, or even those of us who have been writing apps targeting only ACF for years and years and are starting new projects on Railo.

-Nick

On Sunday, March 24, 2013 4:54:21 PM UTC-4, Mark Drew wrote:

Sure. I get it. 

So write it already. 

—
Sent from Mailbox for iPhone

On Sun, Mar 24, 2013 at 4:33 PM, Risto <ck.web...@gmail.com> wrote:

Of course we will have to if that's our only option, but it's also important for the Railo team to understand that your user base does think that a "differences between ACF and Railo" is important.

[Mark Drew]

Surely that is a bug that we must look at? 

Anyway, as I said there is NOTHING stopping any of you creating a page in the wiki detailing these things is there?

Go get em tiger!

—
Sent from Mailbox for iPhone

[Mark Drew]

Hey Adam

There are lies, damned lies and statistics. 

The 30-40% is (as I said) from download feedback submitted. How else could I know? Telepathy is not a skill of mine yet. 

If we take a segment of responders (which,  I have no idea but it is a small minority compared to the total downloads) we could call it a representative sample. And of course they are two different metrics. 

A lot of considerations have gone into that form strangely enough, including that precise tick box  and hopefully it doesn't take a rocket scientist to gather that we want to push commercial services to people that are using Railo Server does it? I mean how else can we fund the development? Fund the sponsoring of conferences, and fund anything else fun (which you can't have fund if you don't have fun!) 

Getting statistics just to know who is new and what other programming languages they are using is not very valuable to us is it? Interesting, sure, but of little value. 

So pushing the name/emails down would defeat the whole goal.

Regards

Mark Drew

[AJ Mercer]

Hi Mark

Did you get a response from GitHub about being able to search pages?

If we are going to have people adding 'random' pages 'everywhere', we will need a way to easily find them.

AJ Mercer
<webonix:net strength="Industrial" /> | <webonix:org community="Open" />
http://twitter.com/webonix

Railo Community Manager

[Mark Drew]

I am working with James to bring the documentation into the website. Then we can search it. 

The wiki would be the editing medium and the site the consumption medium

I want there to be good content. That is what I am really trying to focus on. 

Regards

Mark Drew

Sent from a mobile device

[JEAguilar]

On Wednesday, March 27, 2013 2:55:42 PM UTC-4, Mark Drew wrote:

Surely that is a bug that we must look at? 

https://issues.jboss.org/browse/RAILO-1573

Also,

https://groups.google.com/forum/?fromgroups=#!searchin/railo/sftp/railo/pu4X2ZXrcMI/6CLvWrFdv5IJ and, 

https://groups.google.com/forum/?fromgroups=#!searchin/railo/sftp/railo/g57hFDYMmM0/xmocobn_Q08J among others.

[AJ Mercer]

I wrote up son notes on using Denny's cfssh 

    https://groups.google.com/forum/?fromgroups=#!topic/railo/MC0sEfAoeh0

--

Need help right now? Why not have one of the Railo Team help you directly: http://www.getrailo.com/index.cfm/consulting/
---
You received this message because you are subscribed to the Google Groups "Railo" group.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

[Cameron Childress]

On Wed, Mar 27, 2013 at 2:45 PM, Nick Kwiatkowski wrote:
>> Mark, For example, I found myself struggling 

>> with the lack of SFTP support within the CFFTP tag.

On Wed, Mar 27, 2013 at 2:55 PM, Mark Drew wrote:
> Surely that is a bug that we must look at? 

I don't want to belabor this point any more than it already has been, but I think this little snippet of conversation perfectly illustrates the struggle that the Railo community and leadership is facing when it comes to when it's appropriate to compare ACF and Railo and when it's not appropriate.

Nick is pointing out that SFTP support is not supported by Railo's implementation of the CFFTP tag, nor is this mentioned in the Railo documentation. So, what makes this a bug? It's not a bug, it's simply not a feature Railo includes. Only when compared against ACF's support does it become "a bug". So, the comparison does appear to be critical in this case, even for those who aren't migrating from ACF.

In my mind, this is among the many reasons that I think it's not quite as simple cut and dry to simply declare that Railo is it's own thing going in it's own direction and doesn't need to point out the differences between ACF and Railo, since in the case above, it's the very definition (in this case) of "a bug".

I'm not trying to stir the pot here. I'm not making a soapbox demand that the documentation does or doesn't have to include anything. I think given the budget constraints, and the fact that it's an open source product, it's fair to ask the community to help with this part of the documentation.

However, I would caution the Railo team with language that may be received by observers as a harsh refusal to include ACF vs Railo in certain conversations while using it as the very foundation of other conversations.

This is just my opinion.

-Cameron

--
Cameron Childress
--
p:   678.637.5072
im: cameroncf