Hi Yves!

Thanks, for the quick reply.

On Fri, 29 Jun 2001, Yves Arrouye wrote:

> > >
> > > The URL doesn't look correct. First, I would expect to see
> > >
> > > =09charset=3Dutf-8
> >=20
> > When you look at the original code, there is always=20
> > iso-8859-1 the default charset (for charset and=20
> > responsecharset). Does it mean, that this has to be changed?=20
> > I always get iso-8859-1 for my queries.
>=20
> Oops. It worked at some point, and should work. I guess the answer to tha=
t
> is that in kuriikwsfiltereng.cpp, the definition of rn.m_strQueryWithSear=
ch
> is lacking an
>=20
> =09&responsecharset=3D\\3
>=20
> and also formatting doesn't happen as expected. I'll fix that. Can I comm=
it
> a simple fix like this at this point?

Yes, I'll merge your fixes into my patch then.

>=20
> > I see.
> > I really didn't know that the realname servers use \1 to=20
> > replace the query. That's really hard to support with the new=20
> > syntax, since \1 isn't used anymore the way it was before. It=20
> > will be recognized as old format and treated with the=20
> > compatibility mode (\1 -> \{0})
> >=20
> > The only solutions for this problem I see is the following:=20
> > Don't use \1 in the realname url anymore, but generate the=20
> > whole fallback uri on the client side. The user query will=20
> > appear twice in the realnames uri: Once in the realname=3D term=20
> > and once in fallbackuri=3D as argument to the according=20
> > fallback search engine whithout a \1 in the resulting uri. I=20
> > think it doesn't matter, if we form the fallback uri on the=20
> > client side and don't let this be done by the realname=20
> > server. Another advantage is, that if someone chooses a=20
> > fallback search engine, with a more sophisticated query=20
> > definition, it can be used too with realnames and benefit=20
> > from the advantages of the new query possibilities. Is this=20
> > right, or am I missing something?
>=20
> That would work as long as KDE has all the necessary codecs. And I think =
it
> does. So why not.
>=20
> > The only remaining problem is, that konqueror offers you the=20
> > resolver.dll file to download, instead of interpreting it=20
> > correctly as redirection. But I've got a hint, how this could=20
> > be solved: It seems, that the fallback uri has to be sent to=20
> > realnames with twice encoding, what means, if you have a=20
> > space in the query for google it should look like %20 in the=20
> > uri for google and %2520 (%->%25) in the uri for realnames. A=20
> > quick test confirmed this guess, but I want to look at it=20
> > with more detail.
>=20
> Of course you have to, because the fallbackuri is then going to be reused=
 as
> is for a 302. Now, I say of course, but that escaped me too in your first
> message :-)

Ok, then I think it's time to introduce the suggested (private) method for
substitution and a second private method (eg.
SubstMap getSubstitutionMap(QString userquery)) to make it possible, to
subst both, the realnames uri and the fallback uri.

>=20
> > > If the reencoding didn't happen, and you typed my keyword, Lad=E9d=E9=
,=20
> > > with some extra chars, as in "Que fait Lad=E9d=E9 cet =E9t=E9?" then =
Google=20
> > > will get a UTF-8 query, thinking it's Latin1, and will get all=20
> > > confused.
> > >
> > > So I would just use \wsc_charset for a name, and the fallback URI=20
> > > would have responsecharset=3D\wsc_charset in it if you want,=20
> > instead of=20
> > > the \3 it has now.
> >=20
> > I don't see the difference between charset and=20
> > responsecharset here. Don't you mean charset=3D\{wsc_charset}=20
> > and responsecharset=3D\{wsc_responsecharset}?
> > Note, that the latest patch implements the other syntax, you=20
> > suggested with some enhancements (See mail from Sunday, 24th=20
> > of June for details). This patch used another naming=20
> > (uri_charset, uri_responsecharset), since the naming was not=20
> > yet clear to me.
>=20
> I don't think we should have a \{whatever_responsecharset} it is confusin=
g.
> The response charset is the charset of the Web shortcut. So it would make
> sense to have:
>=20
> =09&responsecharset=3D\{wsc_charset}
>=20
> Now, charset is the charset of the IKW engine, so we could have:
>=20
> =09charset=3D\{ikw_charset}&responsecharset=3D\{wsc_charset}
>=20
> Both ikw_charset and wsc_charset are from m_strCharset, but in one case t=
he
> IKWSEntry has an m_strQueryWithSearch set, and in the other case it does =
not
> (that's how you distinguish between the two). In the case of an IKW engin=
e,
> you get \{ikw_charset} from its m_strCharset, and you get \{wsc_charset}
> from the m_strCharset of the Web shortcut it fallbacks to if it doesn't f=
ind
> a keyword.

Yes, I get it now ;-)

>=20
> YA
>=20

I'll implement my changes on sunday and post a new patch.
Should send it to you privatly, or via the mailing list?

Thanks,
=09Andreas