[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-12 6:35:49
[Download RAW message or body]

Hi!

On Mon, 11 Jun 2001, Dawit Alemayehu wrote:

> On Monday 11 June 2001 14:27, Yves Arrouye wrote:
> > Andreas et al.,
> >
> > BTW, a way to not break backwards compatibility would be to use another
> > character than \ as the magic character for the new syntax. Maybe $ for
> > example. So we would keep \1 and \2 meaning what they mean today, but for
> > automagic splitting one would use $ to refer to specific "fields".
> 
> Good idea except $ is a valid character for thequery component of a URL and as such
> might be incorrectly parsed under some conditions :( Perhaps the "pipe" | would be a
> good replacement since it is not a valid character in a URL ?

Look at the answer to Yves' mail.
I'd like to keep '\' for the reasons of simplicity for the implementation
and the user.
The compatibility mode (treat \1 as \0, when \1 is the only reference in
the query) works really good as well as the more advanced features
(name=Myname with the refernece \name in the query).

> Regards,
> Dawit A.

Perhaps you can agree to my reasons, when I don't want to make the 
algorithm and usage more complicated, if there's really no problem with
the current implementation, which breaks something.

The only misbehaviour which would be possible is the following:
One defines a query with only \1 and intends to only take the first string
of the user query. Since this gets treated as \0 this even works, if the
user uses the query with one user query string.
If he passes more than one string, then it all strings of the user query
substitute \1. But this case should not happen anyway, since it does not
make sense to only use \1 in the query and if so, then to pass more then
one user query string to this qery definition.

I hope this clearifies this point a little bit ;-)

Bye,
	Andreas

PS: Is there a chance to get this patch into KDE-2.2beta1, since I read
that it's already frozen. If not, I hope it will make it into KDE-2.2
final ;-)

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