Hi Naveed, On Sat, Aug 14, 2010 at 11:38 PM, Naveed Massjouni <naveedm9@gmail.com> wrote:

On Sat, Aug 14, 2010 at 10:35 PM, P Kishor <punk.kish@gmail.com> wrote:

...

from http://perlsharedhosting.com/tech/frameworks/dancer

" Note – there is a bug in Dancer version 1.1803 causing routes to work incorrectly under some versions of Apache. Hopefully by the time you read this the bug will be fixed, but in the meantime, edit ~/dancertest/lib/dancertest.pm and change the default route so that it matches all paths: view source print? get r('.*') => sub {    template 'index'; }; "

Well, the above bug still exists, and I am using the latest version of Dancer. I must have wasted close to 3-4 days trying to figure out how to run Dancer with Apache CGI, but the deployment instructions for Dancer are still far from useful.

Of course, I also have had to move dispatch.cgi from within public/ to one level above so Apache can get to it. Its all really incorrect.

Could someone please comment on the state of Dancer deployment?

I am currently updating the deployment docs.  I'm adding a section for deploying on lighttpd via CGI and FastCGI.  If lighttpd is an option for you, I think you will find it much easier to configure and get your app up and running.

Unfortunately, changing web servers is not an option for me, not just on the servers I control, but also on shared web servers on which I have a couple of web sites.

 I suggest that the first section in the deployment docs, named Running as a CGI Script, should be moved under the Apache section.  And it should be re-written from scratch maybe. That way when a new user sees this page, they see the nice ways to deploy stand-alone first.  And if they have to deploy on Apache or lighttpd, they can jump to the corresponding section that they need.

The above sounds like a plan, and I will be happy to contribute toward Apache relevant docs once I am completely successful. Unfortunately, I have hit another roadblock that I will describe in a separate email.

-Naveed

...

Many thanks,

-- Puneet Kishor http://www.punkish.org Carbon Model http://carbonmodel.org Charter Member, Open Source Geospatial Foundation http://www.osgeo.org Science Commons Fellow, http://sciencecommons.org/about/whoweare/kishor Nelson Institute, UW-Madison http://www.nelson.wisc.edu ----------------------------------------------------------------------- Assertions are politics; backing up assertions with evidence is science =======================================================================

On Sun, Aug 15, 2010 at 1:39 AM, sawyer x <xsawyerx@gmail.com> wrote:

On Sun, Aug 15, 2010 at 5:35 AM, P Kishor <punk.kish@gmail.com> wrote:

...

from http://perlsharedhosting.com/tech/frameworks/dancer

" Note – there is a bug in Dancer version 1.1803 causing routes to work incorrectly under some versions of Apache. Hopefully by the time you read this the bug will be fixed, but in the meantime, edit ~/dancertest/lib/dancertest.pm and change the default route so that it matches all paths: view source print? get r('.*') => sub {    template 'index'; }; "

What versions of Apache? Has anyone investigated into this and was able to provide a test case or at least an environment in which it is possible to replicate the issue? Is it in our Github issues?

Perhaps we should contact perlsharedhosting.com.

No need to contact anyone else. I am firsthand experiencing the above bug with Apache2 and Dancer 1.1805. Basically, if trying to deploy with Apache2 under regular CGI or FastCGI, <code>get '/'</code> simply doesn't work. I keep on getting 404. I can break my head against every possible documentation, but I get 404. Change <code>get '/'</code> to <code>get r('.*')</code> and it starts working. With regards to deployment, that is only half of the story, albeit the sordid half. The other half is that Dancer doesn't deploy out of the box. Out of the box, the dispatch.cgi script is under public, so the only way to reach that script is to use the uri http://myapp/public/dispatch.cgi. Therefore, dispatch.cgi needs to be moved one level above public. However, now, all the paths to the css are screwed. So, the paths to the css have to be adjusted from '/css/style.css' to /public/css/style.css' One question -- did anyone actually do the Apache2 CGI deployment before writing those docs, because, as is, those docs don't work at all. I don't know what is better -- not have any docs at all or to have misleading docs. -- Puneet Kishor http://www.punkish.org Carbon Model http://carbonmodel.org Charter Member, Open Source Geospatial Foundation http://www.osgeo.org Science Commons Fellow, http://sciencecommons.org/about/whoweare/kishor Nelson Institute, UW-Madison http://www.nelson.wisc.edu ----------------------------------------------------------------------- Assertions are politics; backing up assertions with evidence is science =======================================================================

On Sun, Aug 15, 2010 at 6:59 AM, sawyer x <xsawyerx@gmail.com> wrote:

On Sun, Aug 15, 2010 at 2:47 PM, P Kishor <punk.kish@gmail.com> wrote:

...

No need to contact anyone else. I am firsthand experiencing the above bug with Apache2 and Dancer 1.1805. Basically, if trying to deploy with Apache2 under regular CGI or FastCGI, <code>get '/'</code> simply doesn't work. I keep on getting 404. I can break my head against every possible documentation, but I get 404. Change <code>get '/'</code> to <code>get r('.*')</code> and it starts working.

Do we already have a ticket on Github issues with this? If not, would you mind opening one? It will be easier for us to track it and fix it. Thank you.

...

With regards to deployment, that is only half of the story, albeit the sordid half. The other half is that Dancer doesn't deploy out of the box. Out of the box, the dispatch.cgi script is under public, so the only way to reach that script is to use the uri http://myapp/public/dispatch.cgi. Therefore, dispatch.cgi needs to be moved one level above public. However, now, all the paths to the css are screwed. So, the paths to the css have to be adjusted from '/css/style.css' to /public/css/style.css'

As it seems, this shouldn't be difficult to fix. If you could please open an issue for this as well, it will solved more quickly.

...

One question -- did anyone actually do the Apache2 CGI deployment before writing those docs, because, as is, those docs don't work at all. I don't know what is better -- not have any docs at all or to have misleading docs.

You should take into account that some people find it hard to interact with people who behave in an offending manner.

Emails have a great potential for being misunderstood, and I think this is one of those classic cases. If I were being offending, or wanted to disrespect anyone's effort, I would have given up on Dancer. I have consistently, in all my emails, maintained that Dancer is a breath of fresh air in the world of web development with Perl. That notwithstanding, my question was simple, did anyone actually do that deployment before writing the docs? Because, as the docs are, and given the current version of Dancer, that deployment would simply not work. I am not talking about just a code bug here. I develop and evangelize open source software, so I know all aspects of how difficult it is to develop software, and that no software is without bugs. That is why we have versions. I am also aware of open source being a non-paid, voluntary effort. I am not expecting anyone to jump to my bidding (although, sometimes, frustration at the same problem may tend to make one sound like that). I am commenting about documentation. If I say in my documentation that something will do "b" when "a", I have basis to say that. Now, what happens with bad documentation is worse than there being no documentation. Most of the time we developers accuse users of not reading the documentation, since most users don't rtfm. However, in this case, the user is diligently reading the docs, and following the instructions to the t. Yet, the stuff is not working. Everyone is bewildered. After a while, the user is either going to start sounding like (and believing that) s/he is wanting others to jump to his bidding, or the user is going to get frustrated and say, to hell with this, life is too short to waste on something that doesn't work as documented.

You're basically disrespecting the effort people have done to create these docs because one documented feature did not work for you. This means the doc might need to be fixed (perhaps a line change) or some of the code has to be fixed. This happens in projects.

Never happened in any project that I have worked with. I can fully expect bugs in the code. But, I can't expect bugs in the instructions on the box. If the box says "Do this and this will happen" then I expect that someone has actually done that. That somewhere in this world, there is a configuration under which that documentation is true. If that is the case, then I can go back to confirming what my configuration is, and then I can say that look, under such and such versions, the documentation doesn't hold true. However, it seems that the particular documentation bug is based on conjecture. I mean, how can http://myapp/dispatch.cgi work if, in the filespace (term used by Apache), I have myapp/public/dispatch.cgi?

I've just recently experienced such documentation discrepancies with App::perlbrew.

The way to get such things fixed is to simply say "Hi, I'm sorry but apparently either the doc is not correct or the code has a bug. Could you please look into this?" instead of giving the impression that all their effort to write the docs (and project) were in vain - which is how you put it.

You misunderstand me, and to the extent that I created that misunderstanding, I apologize. But, look, all my carping will hopefully result in better documentation that is more in sync with reality, and hopefully make Dancer actually say what Dancer does. That would be a good thing, no? :-) I have probably written the most number of emails on this list. I have "bugged" folks on IRC. I have simply not gotten to the bottom of my problem with Dancer now for weeks. It has come to the point that I feel embarrassed asking any question about Dancer now. I always think twice -- am I making a pain of myself? Are folks ignoring me? Am I the only one experiencing this/these problem(s)? Either way, the situation is bad -- the developers and think a member of the community is discourteous and disrespectful, or a member of the community thinks the developers are ignoring him. Either way, that open source project doesn't have a very viable future. The fact is, I want this project to succeed. It is a wonderful change from the usual, confusing swill out there in the Perl web world. But, it is patchy. It needs to be fixed.

This is open source, not a company. We don't get money (at all!) and therefor no one _really_ has to listen to what people say. We do because we care. Telling us that "the docs don't work at all" and that it is not necessarily better than "not having any docs at all" will probably land you in a position of not being often listened to - even if you are reporting an actual bug.

Please, be courteous and respectful. If you find a bug, help us by reporting and try *not* to include any bad-mouthing of people's hard work. Trust me, you'll get more attention and the stuff you care about will get fixed much sooner.

I take your point, but I don't believe it applies here. You have spent more words correcting my possibly wrong attitude than correcting my possible coding mistakes. As I noted above -- proving that the documentation is wrong, and asking if anyone actually tested that before writing it, is not bad-mouting anyone's hard work. I have deep appreciation for the developers behind Dancer. I want this to succeed, to become rock solid, super fast, and dead easy to create and deploy with. That is why I am sticking to it. If my reports and questions lead to better docs and better code, that would be good for everyone. It would be a shame, at least for me, if I come to the conclusion that it is not worth the trouble. Possibly Dancer will thrive without me. But, it would have missed a tree for the forest. Look, all that said, I again apologize if my repeated emails for help with deployment have seemed that they are disrespecting anyone's hard work. That was not the intent.

Thank you.

-- Puneet Kishor

Hi Sawyer, Thanks for your nice email. On Mon, Aug 16, 2010 at 1:33 AM, sawyer x <xsawyerx@gmail.com> wrote:

On Sun, Aug 15, 2010 at 3:30 PM, P Kishor <punk.kish@gmail.com> wrote:

...

[...] did anyone actually do that deployment before writing the docs? Because, as the docs are, and given the current version of Dancer, that deployment would simply not work.

Most likely yes. However, Dancer is pretty volatile and even now had another serious overhaul. These are all blessed changes that mostly stem from user requests, listening to user feedback and taking that feedback and changing Dancer appropriately (even if it means major changes) to make users have something they enjoy working with.

..

Now that we're done with this, I want to thank you for opening the proper tickets in the correct place. That will definitely help track issues.

Would you like to help correct the docs? This is where user experience is the most important!

I will be very happy to. Once again, my apologies if I sounded harsh, but I want to emphasize, my intent is not to be the squeaky wheel that takes up all the available grease. My intent is to make Dancer better. Yesterday, I seriously waffled between trying other "promise the world but still at version 0.0012 alpha quality" web frameworks such as Mojo and Web::Simple, or going back to the "rock-solid but boring as heck" CGI::Application, but was loathe to give up on Dancer (craps, during a momentary lapse of reason, I even though chucking Perl and going with Sinatra, Dancer's original inspiration). There is something very elegant about Dancer's approach, and I didn't quite feel ready to wave it goodbye. Here is what I want to do -- I have three different apps, app1, app2, and app3. These can be placed anywhere on the filesystem. Heck, they could even be on three different computers eventually. That is how I want. Three apps capable of standing on their own. However, these apps are related. They are accessed like so: app1: http://server/app1 app2: http://server/app1/app2 app3: http://server/app1/app3 In that sense, app1 is kinda like a mother-app, and app2 and app3 "inherit" from app1. The child-apps look like app1, they have the same menus, just one level deeper (see below for an "image"), and share the authentication mechanism. When I created this set of applications with CGI::Application, I created a master app, and then inherited apps[1..3] from the master app. Anyway, that is the design. Now, wrt deployment, it has to work with Apache(2). There is no question about that. As I said before, even on my personally controlled servers, Apache is already installed, and is a prerequisite for a couple of other projects, so I just can't manage complexity by way of alternative web servers. Also, on my shared host web sites, Apache is the backbone. Also, for starters, it has to work with Apache CGI. Eventually, I will move to a more persistent environment such as mod_perl (most likely -- has anyone tried mod_psgi yet?). Soon, as I am completely successful in creating the above scenario, I will write detailed instructions that even a newbie like me would be able to follow. That is my promised contribution to the Dancer project. Many thanks for your help. And, hey, many thanks for the Dancer::Template::Tiny wrapper. That is what I am using. It is brilliantly simple and fast. -- Puneet Kishor http://www.punkish.org Carbon Model http://carbonmodel.org Charter Member, Open Source Geospatial Foundation http://www.osgeo.org Science Commons Fellow, http://sciencecommons.org/about/whoweare/kishor Nelson Institute, UW-Madison http://www.nelson.wisc.edu ----------------------------------------------------------------------- Assertions are politics; backing up assertions with evidence is science =======================================================================

On Sun, Aug 15, 2010 at 6:59 AM, sawyer x <xsawyerx@gmail.com> wrote:

Do we already have a ticket on Github issues with this? If not, would you mind opening one? It will be easier for us to track it and fix it. Thank you.

Done. http://github.com/sukria/Dancer/issues/issue/99 -- Puneet Kishor http://www.punkish.org Carbon Model http://carbonmodel.org Charter Member, Open Source Geospatial Foundation http://www.osgeo.org Science Commons Fellow, http://sciencecommons.org/about/whoweare/kishor Nelson Institute, UW-Madison http://www.nelson.wisc.edu ----------------------------------------------------------------------- Assertions are politics; backing up assertions with evidence is science =======================================================================