gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnu-arch-users] Re: Obsoleting abrowse


From: Matthieu Moy
Subject: [Gnu-arch-users] Re: Obsoleting abrowse
Date: Thu, 11 Aug 2005 00:22:54 +0200
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)

[ sorry for the late reply ]

Mikhael Goikhman <address@hidden> writes:

> On 03 Aug 2005 00:45:48 +0200, Matthieu Moy wrote:
>> 
>> I'm now convinced we have to let abrowse in 1.5. It's currently
>> obsoleted in the sense "not in the output of baz help, and displays a
>> warning stating that it will be removed". Newcomers will learn to use
>> browse, which is the way of the future, while long time users will
>> almost not see the difference.
>
> I disagree. I think many people here have archives in the non-flat format
> (I have). From my point of view a new "browse" command:
>
>   * removes the functionality that we extensively use in arch-magic
>   * is less clean (should always append "--" to get predictable results)
>   * is slower (50 seconds rbrowse vus 30 seconds abrowse for my archive;
>     queries with limit may be even more slow, 30 sec vus 10 sec)

I've identified and fixed another performance issue in browse. with no
limit, "browse" is now as fast as "abrowse" (there's still a small
performance overhead when using a limit, with a tla 1.0 archive).

> Please leave abrowse as-is during 2005 and do not add any warning to it.

The warning is just one line, sent to stderr, so, it doesn't harm. The
problem is that the upcomming namespace change might mean rewritting
abrowse almost from scratch, and I don't think anyone is willing to do
it (if you are, then I'm OK to remove the warning). This means abrowse
will be in 1.5, but may well have to be dropped for 1.6.

More generally, we have to discuss and anticipate what the new
namespace will look like before releasing the 1.5, so that we can push
the users towards the new way to do. (I also think we need some kind
of categorization and filtering, but the a/c--b--v is too rigid. I
don't like it and many other users don't like it either)

> I'd still prefer these problems to be solved at some point. I am also
> fine with not removing a more functional 

browse also has features that abrowse doesn't have. One is not "more
functional", just different.

-- 
Matthieu




reply via email to

[Prev in Thread] Current Thread [Next in Thread]