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

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

Re: [Gnu-arch-users] tla archives return value


From: Tom Lord
Subject: Re: [Gnu-arch-users] tla archives return value
Date: Sun, 12 Oct 2003 07:51:16 -0700 (PDT)

    > From: Paul Hedderly <address@hidden>

    > > > Could always just look in .arch-parms/=locations ?

    > > Yuck. Then I'd be dependent on that staying the same. There's a reason
    > > for published interfaces.

    > But I thought tla was meant to be just an implementation of the arch
    > protocol (ok the reference implementation), and not the only way of
    > working with an archive.

    > What I'm saying is that you'd be using a published interface.


I suspect that rbcollins is is making the safer bet.

That aside, when you talk about there being mulitple, interoperating
implementations -- yes, that's the goal (and, partially, the result).

To really support that goal properly, we will need to formally
document some things.

         * changeset formats and project tree formats
         * the namespace and taxonomy of revision types
         * fs-based archive layout, and the mapping of txns onto the
           simple transports 

Those are sufficient to create interoperable clients and contain
nothing not needed to to create interoperable clients.   The details
of ~/.arch-params are not in that list.

If we believe in a future where people write "smart servers", then we
also need to standardize the vtable in src/tla/libarch/archive.h (Not
as C code so much as an abstract API and one or more RPC protocols.)

A secondary goal _might_ be to have "swappable" clients -- so that if
I'm using one I can switch to the other without having to reconfigure
anything.   _That's_ the context in which we'd want a standard for 
~/.arch-params.

Another secondary goal _might_ be to have "workalike" clients -- so
that if I'm using one I can substitute another and still use all the
same command lines (assuming that I stick to a standardized subset).   
That's the context in which we'd want a standard for the command line
interface.  

The connection between what Rob is doing and the idea of interoperable
clients relates only to those two secondary goals, not to the primary
interop goal.   In other words, the interop goals don't really give us
much advice about what the right thing for Rob to do is.

-t





reply via email to

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