aMule Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

We're back! (IN POG FORM)

Pages: 1 [2]

Author Topic: Portability issues on unices  (Read 9324 times)

lfroen

  • Guest
Re: Portability issues on unices
« Reply #15 on: May 22, 2008, 08:46:43 PM »

Yeah, that you refuse to remove a format spec that doesn't exist in some implementations ;)
Refuse to remove? Should I start quote myself?

IMHO, printf should be avoided for C++ implementations and std::cout used.
<shrugs>

Anyway, my question stands, why is amuleweb printing anything like that to the console? That doesn't seem to be a informative message for the user.
For 2 purposes:
1. For messages about syntax errors in script
2. For printing output of var_dump() of php script, which is used for page debugging.

Those are not messages for user, but for page developer.
Logged

GonoszTopi

  • The current man in charge of most things.
  • Administrator
  • Hero Member
  • *****
  • Karma: 169
  • Offline Offline
  • Posts: 2685
Re: Portability issues on unices
« Reply #16 on: May 22, 2008, 09:06:39 PM »

Anyway, my question stands, why is amuleweb printing anything like that to the console? That doesn't seem to be a informative message for the user.
For 2 purposes:
1. For messages about syntax errors in script
2. For printing output of var_dump() of php script, which is used for page debugging.

Those are not messages for user, but for page developer.

IMHO both should be reported to the requester.

I mean if I was a page developer and I found that the PHP engine prints var_dump() to somewhere else than the resulting HTML page, I would be very disappointed. The same applies to syntax errors in scripts: the resulting page should describe the error.

I mean this is the behaviour of all PHP interpreters I know, why should amuleweb differ?

Not to mention that there's no console to print to if amuleweb was started automagically by amule(d).
Logged
concordia cum veritate

Gaznevada

  • Jr. Member
  • **
  • Karma: 3
  • Offline Offline
  • Posts: 51
Re: Portability issues on unices
« Reply #17 on: May 22, 2008, 10:04:20 PM »

We all know the application mustn't crash. We're talking solutions.

Reading previous posts, that wasn't so clear to me. Anyway.

--
Gaznevada
Logged
--
"Orwell was an optimist" - Usenet, somewhere.

lfroen

  • Guest
Re: Portability issues on unices
« Reply #18 on: May 23, 2008, 12:29:09 PM »

IMHO both should be reported to the requester.
This is wrong all over. For real web application this may easy become security issue. ALL errors (from database, script, etc) should be reported to apache log, and not to page requester.

I mean if I was a page developer and I found that the PHP engine prints var_dump() to somewhere else than the resulting HTML page, I would be very disappointed. The same applies to syntax errors in scripts: the resulting page should describe the error.
This suggest that you never seen real PHP (or ASP or CGI), because this is exactly how it works. Errors going to apache log or to stderr when running standalone.

There's also technical reason for this behavior. You can't just dump your error message in the middle of HTML page. You don't know the context, so there's no way to ensure your error message is visible.

I mean this is the behaviour of all PHP interpreters I know, why should amuleweb differ?
That's exactly my point, you see.

Not to mention that there's no console to print to if amuleweb was started automagically by amule(d).
This because amuleweb is not real webservser, which typically have log file. I may add option for amuleweb to create log for this very purpose, but it looks like overkill to me. There's not many people going to develop templates IMHO, and those who do can start it from command line: "amuleweb -q" isn't very complicated command.

Logged
Pages: 1 [2]