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

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.

Thank you.