[Top][All Lists]

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

Re: [Gnu-arch-users] archzoom wishlist item

From: Jim Lynch
Subject: Re: [Gnu-arch-users] archzoom wishlist item
Date: Sun, 22 Aug 2004 07:49:42 -0700

On Sat, 21 Aug 2004 15:39:58 +0000
Mikhael Goikhman <address@hidden> wrote:

> On 21 Aug 2004 15:11:57 +0200, Johannes Berg wrote:
> > 
> > Currently pages like
> >
> > 
> > are structured in category -> branch -> version
> > 
> > A nice to have alternative view would be
> >   category -> version -> branch
> I don't know. Diverging from the arch's idea of structure does not sound
> too appealing to me.  [BTW, I hope/think this is the correct usage of word
> "diverge", so such name would be unintuitive to mean "branch" or "fork".]
> I guess you should lobby Tom and others to change the arch namespace
> itself. 

But if this was done every time someone simply wanted a different view
of the data (which I do, see a few msgs ago), the internal structure of
arch would become a total mess and things would change too fast and for
the wrong reasons. Would you change the format of C strings just because
you wanted to send the terminal a '\0' as part of hello.c? :) No, you'd
use a call that was capable of sending a \0.

My personal reason for wanting a different view of the arch data is to
find toys to play with^w^w^w^wprojects to look at, and so I thought a
sorted list of all categories in a collection of archives might be a way
to accomplish being able to find things, failing of course being -told-
by someone "Oh yes, I work on a thing you might be interested in, it's
at this place: ____." There is no way at all this would be a reason to
change anything about the underlying structure of arch, just because I
want to find toys and I also think others might want to perform the same
type of search: it's accomplishable without changing the internal
structure, and even shouldn't change anything about tla/arch.

Look at projects like cscvs: I believe (without looking too closely)
it accomplishes its purpose by using tla and using cvs as abstraction
barriers beyond which isn't its concern. It can get everything it 
needs about a cvs repo without looking at internals of cvs, and it
can translate what it finds into an arch repo by going no further
than using tla. Because it works this way, it is at least partially
independent of what happens to change internal structures of both
arch and cvs. So, it is an interface between two interfaces, iiuc.

> Regards,
> Mikhael.


Jam sessions community web site:

reply via email to

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