[Dancer-users] dancer bug

[P Kishor]

On Sun, Aug 15, 2010 at 6:59 AM, sawyer x <xsawyerx at gmail.com> wrote:
> On Sun, Aug 15, 2010 at 2:47 PM, P Kishor <punk.kish at 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