> After looking at the current defined messages I think we already have t=
oo
> much specific error codes that would have been better served with e.g.
>ERR_SLAVE_DEFINED. I don't want remove existing error codes but I don't
> think we should add more error codes unless that kind of error is eithe=
r
> common for many slaves or it is needed for the automatic handling of su=
ch a
> response. (Eg. like the ERR_UNSUPPORTED_ACTION which makes that a job w=
ill
> try do what it wants to do in an alternative way)

I agree with this. The only problem is that, at the moment, ERR_SLAVE_DEF=
INED=20
won't fit into the formatting structure of the code I have been working o=
n:

QString errorName - the 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 possible solutions for the error
QString techName - if not null, the more technical name for the error

If we wanted a slave's custom error to look the same if/when this is turn=
ed on=20
for 3.1, we could:

1) add a new method to SlaveBase as below. If this breaks runtime=20
compatability (I don't know) this would prevent kde2 apps from being able=
 to=20
use kde3 ioslaves; however it would be a much cleaner api:

void customError(const QString& errorName, const QString& description, co=
nst=20
QStringList& causes, const QStringList& solutions, const QString& techNam=
e =3D=20
QString::null)

2) require the QString errorText that is passed with the current error ca=
ll to=20
be a QByteArray which has had the above objects streamed in, and then pul=
l=20
them out at the other end.

Either of the above options would enable slaves to deliver error messages=
 in a=20
nice format, and for them to provide detailed and accurate assistance to =
the=20
user.

Thoughts?

Hamish