[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:       Andreas Hochsteger <e9625392 () student ! tuwien ! ac ! at>
Date:       2001-06-30 7:34:44
[Download RAW message or body]

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
> > >
> > > 	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?

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

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

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.

> 
> > > 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.

Yes, I get it now ;-)

> 
> YA
> 

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

Thanks,
	Andreas

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