[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:       Dawit Alemayehu <adawit () kde ! org>
Date:       2001-06-12 7:50:39
[Download RAW message or body]

On Tuesday 12 June 2001 02:35, Andreas Hochsteger wrote:
> 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).

Well I could not test that because you did not provide me with the
.desktop file that defines your new "tel:" or anything else that uses
the new scheme :)

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

You did not have to re-explain, I have no problems with the approach you take
so long as it does not break anything else :)  I was just pointing out to Yves that
we cannot $.  And from the qucik testing I did using the entry Yves provided as
well as the concern I had, your patch seems to work correctly ; so the only thing
left to do is go through the code again to make sure we have no gottchous which I
will do tomorrow and commit it if I do not see any issues with it.  However, before I
do that I need a patch for all the .desktop files that converts them to the new format :)


Regards,
Dawit A.

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