[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: KIO/KHTML Error Handling Update
From:       Hamish Rodda <meddie () yoyo ! cc ! monash ! edu ! au>
Date:       2002-01-27 5:59:00
[Download RAW message or body]

I moved this to the top because it's more important than what is going on 
below:

>PS: I would really have appreciated to see a patch first about this. I don't
>want to be picky but you actually broke the feature freeze and added tons of
>new i18n strings to kdelibs for the translators - not very nice as we're
>heading for a release quite soon.

I know that this is late, and I am sorry for causing such trouble. If you feel 
that reversing this patch is the best thing to do, I will do so without 
hesitation :)

This came up from trying to get webdav to produce sensible errors. It was only 
a few days ago that I realised that the root of the problem was much deeper 
than just the format of the strings that I was sending.

From what I have seen, taking care of error messages has not been given a 
large priority in the past, understandably so because there are more 
important and interesting things to do. As I see it, kio will only produce 
more useful and specific error messages when the meaning of errorText can be 
better defined than it is now (be that a per-error definition or a general 
"additional information about the error" definition).

For what it's worth (wrt feature freeze), ie. not much, I did get the 
impression from discussions here yesterday that i18n was not frozen for 
another 3 days, and that the change would be ok being reviewed post-commit 
(see the thread "KIOSlave errors an konqueror's handling of them" between 
David and I). I felt I was acting in good faith because I consider poor error 
reporting to be more of a user interface bug than a feature... to me it's 
something that should just be done right.

The i18n changes are not as big as they look because many of the strings are 
duplicated exactly. I was originally going to put the error messages in a 
html page to be served up on error, but Lauri told me that they would not be 
translated... in the end I think the i18n() calls are a much better solution 
because of the high rate of repetition.

So, please tell me if you think this has come at too much of a wrong time, and 
I will revert the changes and store them away for another day :)

>On Son, 27 Jan 2002, Hamish Rodda wrote:
>> I have also committed the changes to khtml_part and konq_run. The error://
>> sub-URL code is commented out because it doesn't appear to work - David,
>> could you have a look? do a search for "rodda", it's commented.
>
>It generates quite funny error messages:
>
>The specified file or directory The file or directory /path/to/file does
>not exist. does not exist.

This is the problem that I was trying to work around in the first place - 
kioslave writers haven't really known what to pass in errorText. This has led 
to inconsistent error messages from KIO a large percentage of the time.

For the most part I switched to using the URL rather than the errorText, this 
would be one place that hasn't been switched that I would fix.

>the "<a>click here</a> for documentation" style of documentation is bad
>style. because it includes and highlights the "click here" part, which
>doesn't contain any useful information (and besides that one doesn't have to
>click - one could use the keyboard as well).

I could remove that or put the real URL somewhere higher so it is refreshed 
instead.

>Having a short look at the possible causes and solutions you added to
>global.cpp it makes me wonder if we should really include this section, and
>if it should be really hardcoded in kio. I wonder because that part of the
>code does not have the slightest idea of the origin and the cause of the
>error, so it is really unable to give out any advises. i.e. giving the
>advise to mail webmaster@<givenhost> is really inapropiate for ftp
>urls. I don't like to resemble IE's braindamage that reports every error as
>DNS or Server failure. At _least_ the advises should be set by the ioslave
>producing the error.

Good point, I tried to avoid most of the braindamage and that's one of the 
things I missed. Another is the use of the word server, as KIO isn't 
necessarily talking to a server all of the time, though mostly it is.

I myself hate IE's handling, and wouldn't be submitting this if I didn't think 
it could be done "right enough" to be worthwhile.

Unless we were to extend the kio error reporting api, the best we can do is 
give as general advice as required to aviod such braindamage.

>Besides that, I don't think doing this inside KIO is the right place. I#ve
>originally added the showError hook to khtmlpart to exactly add that
>descriptive error message at that point - and give applications using
>khtmlpart the possibility to fully customize the error messages and to
>"filter" them.

Many of the errors are more likely to be shown in an errorDialog from 
KIO::Job, especially from other ioslaves, which I was just in the process of 
switching from the old string to the new detailed description, hidden away 
under a "details >>" button.. More reasoning below too.

>Possible uses is the browser in a kiosk mode application. In such an
>environment telling as solution to "mail the administrator of the system" is
>really inapropiate. A kiosk browser that is using a ISDN network connection
>could then check upon a host name lookup failure if the ISDN network
>connection is still alive - if it is not, it could then generate a more
>appropiate cause and solution part than KIO could ever think of.

This sounds like an opportunity for the kiosk browser to override showError. 
Otherwise isn't what we are talking about extending KIO, but then who is 
going to do that?

>Given the broad number of causes and broad number of possible solutions I
>don't think the current way of handling it is good, read: putting this in
>KIO is misplaced and will give us more headaches in the future than those
>"fancied" error messages give an advantage for now.

I think you are right about the method buildHTMLErrorString, but I tend to 
disagree about rawErrorData.

buildHTMLErrorString could easily be moved to KHTML, and indeed this makes a 
lot of sense (I don't know why I didn't think of this before).

rawErrorData: if KIO eventually was given an expanded error reporting API, the 
causes and solutions for each problem would be better known and thus reported 
more specifically by changes only within kio. FYI, the output of rawErrorData 
is such:

QString errorName - the name of the error
QString techName - if not null, the more technical name of the error
QString description - a description of the error
QStringList causes - a list of possible causes of the error
QStringList solutions - a list of solutions for the error

If kio could communicate better internally, the causes and solutions lists 
would be shorter and more specific, without khtml or any other app trying to 
use the interface having to be modified.  If this was moved to khtml, both 
khtml and kio would have to be updated to produce more specific output, as 
you explain here..

>I would vote for extending the showError() interface in khtmlpart with the
>necessary parameters (like a pointer to the "details" structure that tells
>you about url, protocol, date, description etc). it might even be clever to
>be able to pass some details from within the kioslave to the app this way
>(like a qstring <-> qstring map).


>Just my 0.02 Euro,
>
>
>Dirk

Thanks for your time and opinions, they were very useful, much more than 0.02 
Euro...

Cheers,

Hamish
[prev in list] [next in list] [prev in thread] [next in thread]