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

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

Re: [Gnu-arch-users] Regarding pyarch future


From: David Allouche
Subject: Re: [Gnu-arch-users] Regarding pyarch future
Date: Wed, 11 May 2005 15:30:39 +0200

On Sun, 2005-05-08 at 10:29 -0500, John A Meinel wrote:
> I think a lot of it is if we could define what "Arch" is. I know it was
> mentioned in the past about writing actual documents. I think we could
> discuss on the list, but probably as Migo says #arch might be better.
> 
> Stuff like: archives, working trees, namespaces, etc.
> 
> Once you get it back down to what the basics are, then you can start
> creating meaningful set of functions/objects, and use the _impl pattern
> to instantiate things based on the backend.

I think you tend to get saner results when working top-down instead of
bottom-up. But maybe it was only my own shortcomings.

If the oft-hoped-for specification process should materialise, I'd be
happy to give it my two cents.

> Can you give specific examples of how it is a better model? I've tried
> to look through the documents, and while I don't agree with everything
> that is said, it still seems interesting.

That's is not the right place to talk about it. But I'll give it a quick
try, hoping not to start a flame. There's more to Baz-NG than what I'm
mentioning here (for example the inventory system looks like it is much
more practical), but I'm focusing on abstract core model differences.

In a nutshell, what I regard as the good things in the Baz-NG model,
compared to the Arch model, are:

      * The economy in the design: as few core concepts as possible.
              * For instance, there is no fundamental distinction
                between trees and repositories. But that does not
                exclude trees without explicit history data (akin to
                Arch trees) or trees without explicit source files (akin
                to Arch archives).
      * The decoupling of naming, storage and identification.
              * That is the removal of the Arch namespace as a core
                concept. Important use cases of the namespace can still
                be supported by non-core tools and best practices.

If it is not obvious why these are really good things, it could be
lengthy to explain.

What is good is what you cannot see, because is not there.
-- 
                                                            -- ddaa

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

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