Re: [Gnu-arch-users] Preliminary Arch Cache available

[Tom Lord]

This sounds like a change that should (if it is good) eventually
impact lots of code.  In other words: it introduces new idioms at some
levels in tla.  People writing future code should be aware of when and
how to use your new APIs or more aware of how old APIs are effected by
this change.  It might impact with other changes that are planned.

It was for reasons such as those that I first raised a discussion
about what the right abstraction is for a general cache.   I'm not
convinced a good design can be converged on in increments without a
clear idea of what the ultimate target is.

It also sounds like a change that impacts, in an unusually significant
way, the per-user "state" maintained by tla.  Here is a whole new
thing besides ~/.arch-params, wds, and revlibs.  This, in particular,
means that the change (if applied to mainline) can raise lots of
future compatability issues.

Your description sounds nice, but it lacks any help at all for someone
wanting to review your new APIs, proposed new internal programming
conventions, and impact on per-user state.

I could look at the code and try to guess that information --- but my
guess will be based on what you did rather than what you intended to
do.   Even if those two are compatible, getting from code to intent
can be tricky and even impossible.   For example, it would be
difficult to distinguish some part of your code that is "provisional"
from what that is intended to faithfully implement the concept.

Would you be willing to write a more complete presentation, please?
Or if you already have one, post *that* with your announcement?

-t



    > X-42-Pre-Check: Attempted
    > Date: Mon, 13 Sep 2004 09:17:13 -0400
    > From: Aaron Bentley <address@hidden>
    > User-Agent: Mozilla Thunderbird 0.5 (X11/20040309)
    > X-Accept-Language: en-us, en
    > Content-Type: text/plain; charset=us-ascii; format=flowed
    > X-Panometrics-MailScanner: Found to be clean
    > X-BeenThere: address@hidden
    > X-Mailman-Version: 2.1.5
    > Precedence: list
    > List-Id: a discussion list for all things arch-ish 
<gnu-arch-users.gnu.org>
    > List-Unsubscribe: <http://lists.gnu.org/mailman/listinfo/gnu-arch-users>,
    >   <mailto:address@hidden>
    > List-Archive: <http://lists.gnu.org/pipermail/gnu-arch-users>
    > List-Post: <mailto:address@hidden>
    > List-Help: <mailto:address@hidden>
    > List-Subscribe: <http://lists.gnu.org/mailman/listinfo/gnu-arch-users>,
    >   <mailto:address@hidden>
    > Sender: address@hidden
    > X-Spam-Checker-Version: SpamAssassin 2.64-42mail (2004-01-11) on 
    >   mail.42inc.com
    > X-Spam-DCC: sonic.net: mail 1117; Body=3 Fuz1=1 Fuz2=3
    > X-Spam-Status: No, hits=-4.2 required=4.5 tests=AWL,BAYES_00 
autolearn=ham 
    >   version=2.64-42mail
    > X-42email-MailScanner-Information: Please contact 
http://www.42inc.com/support.html for more information.
    > X-42email-MailScanner: Found to be clean
    > X-UIDL: 8d65438e7aa3c2c8038ae99ac13114f1
    > 
    > 
    > Hi all,
    > 
    > Over this weekend, I've added support for a persistent, disk-based, 
    > local cache to Arch.
    > 
    > It's intended to be a general cache of persistent data, as I discussed 
    > w/Tom.  Right now, I've implemented it at the archive level, but it 
    > could be applied to higher levels.  The goal of archive caching is to 
    > avoid downloading the same data multiple times.
    > 
    > It provides an alternative to partial mirrors, for connected operation
    > 
    > Comparison with partial mirrors:
    > Pro:
    > 1. Always up to date
    > 2. Never downloads anything you don't need
    > 3. Allows you to commit
    > 
    > Con:
    > 4. Still requires a connection before using the cache
    > 
    > How to get and use it:
    > get it from here:
    > 
    > address@hidden/tlasrc--cache--0
    > http://sourcecontrol.net/~abentley/archives/tlasrc/
    > 
    > tell Arch where your cache belongs:
    > echo $ANYPATH > ~/.arch-params/=arch-cache
    > 
    > Register an archive for use with cache:
    > tla register-archive -f 
    > cache:http://sourcecontrol.net/~abentley/archives/tlasrc/
    > 
    > Only archives with cache: preceeding their normal URL will be cached.
    > 
    > Status of the code:
    > The caching code is only active for archives with cached: in their URLs. 
    >   It's new code, and changes to existing files are very minimal. 
    > Furthermore, most of the new code is just wrapper code.  I modified the 
    > test suite to use cached: URLs everywhere, and it passes the test suite.
    > 
    > However, there may be changes yet to the Arch Cache namespace, so your 
    > cached data may become obsolete in a future.
    > 
    > It's based on my development branch, containing the backbuilder and 
    > other changes, like commit --base.  If you don't want those, you can do
    > this, instead:
    > 
    > # Actually, any tla more recent than 1.1 should work
    > $ tla get address@hidden/tla--devo--1.2 cache
    > $ cd cache
    > $ tla apply-delta 
    > address@hidden/tlasrc--cache--0--patch-2 $(tla 
    > revisions -f address@hidden/tlasrc--cache--0|tail -n 1)
    > 
    > What's missing:
    > - Ancestry data is not cached
    > - Revision type data is not cached
    > - Lazy initialization would be very nice (there are issues with this 
    > that I'll detail in a followup email)
    > - If a cacherev is downloaded, it should still be usable if the cacherev 
    > is removed from the original archive
    > - Easy commandline tools, e.g. tla my-arch-cache
    > - Support for disconnected operation
    > 
    > Aaron
    > 
    > -- 
    > Aaron Bentley
    > Director of Technology
    > Panometrics, Inc.
    > 
    > 
    > _______________________________________________
    > Gnu-arch-users mailing list
    > address@hidden
    > http://lists.gnu.org/mailman/listinfo/gnu-arch-users
    > 
    > GNU arch home page:
    > http://savannah.gnu.org/projects/gnu-arch/
    > 
    >