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

List:       kfm-devel
Subject:    RE: A more flexible solution for internet keywords
From:       Yves Arrouye <yves () realnames ! com>
Date:       2001-06-29 18:43:24
[Download RAW message or body]

> >
> > The URL doesn't look correct. First, I would expect to see
> >
> > 	charset=utf-8
> 
> When you look at the original code, there is always 
> iso-8859-1 the default charset (for charset and 
> responsecharset). Does it mean, that this has to be changed? 
> I always get iso-8859-1 for my queries.

Oops. It worked at some point, and should work. I guess the answer to that
is that in kuriikwsfiltereng.cpp, the definition of rn.m_strQueryWithSearch
is lacking an

	&responsecharset=\\3

and also formatting doesn't happen as expected. I'll fix that. Can I commit
a simple fix like this at this point?

> I see.
> I really didn't know that the realname servers use \1 to 
> replace the query. That's really hard to support with the new 
> syntax, since \1 isn't used anymore the way it was before. It 
> will be recognized as old format and treated with the 
> compatibility mode (\1 -> \{0})
> 
> The only solutions for this problem I see is the following: 
> Don't use \1 in the realname url anymore, but generate the 
> whole fallback uri on the client side. The user query will 
> appear twice in the realnames uri: Once in the realname= term 
> and once in fallbackuri= as argument to the according 
> fallback search engine whithout a \1 in the resulting uri. I 
> think it doesn't matter, if we form the fallback uri on the 
> client side and don't let this be done by the realname 
> server. Another advantage is, that if someone chooses a 
> fallback search engine, with a more sophisticated query 
> definition, it can be used too with realnames and benefit 
> from the advantages of the new query possibilities. Is this 
> right, or am I missing something?

That would work as long as KDE has all the necessary codecs. And I think it
does. So why not.

> The only remaining problem is, that konqueror offers you the 
> resolver.dll file to download, instead of interpreting it 
> correctly as redirection. But I've got a hint, how this could 
> be solved: It seems, that the fallback uri has to be sent to 
> realnames with twice encoding, what means, if you have a 
> space in the query for google it should look like %20 in the 
> uri for google and %2520 (%->%25) in the uri for realnames. A 
> quick test confirmed this guess, but I want to look at it 
> with more detail.

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 :-)

> > If the reencoding didn't happen, and you typed my keyword, Ladédé, 
> > with some extra chars, as in "Que fait Ladédé cet été?" then Google 
> > will get a UTF-8 query, thinking it's Latin1, and will get all 
> > confused.
> >
> > So I would just use \wsc_charset for a name, and the fallback URI 
> > would have responsecharset=\wsc_charset in it if you want, 
> instead of 
> > the \3 it has now.
> 
> I don't see the difference between charset and 
> responsecharset here. Don't you mean charset=\{wsc_charset} 
> and responsecharset=\{wsc_responsecharset}?
> Note, that the latest patch implements the other syntax, you 
> suggested with some enhancements (See mail from Sunday, 24th 
> of June for details). This patch used another naming 
> (uri_charset, uri_responsecharset), since the naming was not 
> yet clear to me.

I don't think we should have a \{whatever_responsecharset} it is confusing.
The response charset is the charset of the Web shortcut. So it would make
sense to have:

	&responsecharset=\{wsc_charset}

Now, charset is the charset of the IKW engine, so we could have:

	charset=\{ikw_charset}&responsecharset=\{wsc_charset}

Both ikw_charset and wsc_charset are from m_strCharset, but in one case the
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 engine,
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 find
a keyword.

YA

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