Re: [Gnu-arch-users] feature plans from over here....

[Tom Lord]

    > From: address@hidden (James Blackwell)

    > I like the idea conceptually, but I think it could stand an improvement
    > or two...

For that reason, and to give a heads up to other developers that I
want to "own" the ~/.arch-params format for the next few weeks, are
why I posted.


    > 1. I really like the role based setup, in which there's a (still human
    > readable) .arch-params equivilant. However, rather than tying the role
    > to the my-id, I think we should have "role names" instead. 

That is, in fact, how my colleague has speced it out.   

This is a small enough change (although it sets a stage for later more
substantial changes) so I think we'll just wait to post the merge
request rather than trying to debate a detailed spec in advance.....
the guy doing the work might decide to disagree with that, though :-)


    > These names
    > would fit the format of [a-zA-Z0-0_-]+. For example, valid role names
    > would be "arch", "archdev", "canonical" and "default". When a new user
    > is set up for the first time, put them in the "default" role. We want
    > this change because it shortens what users have to type. We don't have
    > to worry about namespace changes because I think these role names should
    > be local.

Right.

    > 2. re archive aliases. Nah. I think we should have fully qualified
    > aliases. I.E. jbdev expands to address@hidden/tla--devo--1.2, 
    > tomtla expands to address@hidden/tla--devo, so forth and so on.

This is just a first step towards that.

We have divided up our plans into three functional areas:

        1. Archive management
        2. Revlib (and other client-side cache) management
        3. Project tree management

Those aren't, obviously, completely separate areas of functionality.
They interact with one another a lot.   

But as we imagine more and more (in many cases) separation of the
roles of "site arch administrator" and "arch user", then the three
functional areas are a good map of how people's jobs break down.
At scale (and as exemplified by Arch's own infrastructure), we've got
people managing large collections of archives (e.g., you and the super
mirror).  It's forseeable that we'll have people managing shared or
"super-" revlibs.   

It seems healthy to me to have people in those roles for large
projects.  So we're going to add some features to help define and
optimize those roles.


    > 3. Re: Keeping all of the archive locations in one file: You must have
    > read my mind, because Robert and I discussed his just the other day.

You must have misread my mind because that isn't quite what I meant.

You could think of archive registrations, in spite of the fact they
are regular files, as a kind of relational table.   A very simple
table of two columns:

        archive-name            archive-location

I haven't said anything about how we plan to change the physical
layout of that database (i.e., i didn't mean to say "all in one
file").

But I am talking about a "table layout" change.   Part of that change
will be to have a table indexed by unique archive-locations and that
table will also include information like mirroring policies.

The rough idea is that users have a low-level, hat-independent
database of the archives they know about.   Archive-specific data
(like mirroring or backup policies) go in that low-level database.
At the same time, users have a higher-level hat-specific database.
In that higher-level database, hat-specific nicknames for particular
archive locations can be added.

(And then, later, we'll add some other stuff to hats and some
additional structure to ~/.arch-params.)



    > The rest of it, I think I like it as is, though I'm a little
    > nervous on he transactualizinaterating .arch-params,
    > particularly when it comes to merging hooks.

Merging in ~/.arch-params is, for the most part, going to be a special
case.   I.e., arch will have some built-in rules that know how to do
merging ops on ~/.arch-params without using `patch(1)' at all.

-t