Re: [Gnu-arch-users] Archive metadata

[David Allouche]

On Fri, Jan 23, 2004 at 03:10:25PM -0800, Tom Lord wrote:
> 1) I'm a little nervous about the idea of a generic "metadata"
>    facility.
> 
>    I'd generally rather see a generic design pattern for "metadata" --
>    applied in specific cases -- but I'm not so sure about new
>    "metadata commands".

Really, deep down, there is no essential reason to use "metadata
commands" to implement my proposal.

After a thought a bit about it, I realized that the cache locking
mechanism was not really needed, there are two use cases for locking:

  1. Locking for read, so data does not change under one's feet.

  This actually can be handled by temporary directories. No need to put
  stuff in a shared cache. Just get the tree in a
  ,,metadata-<feature>-<unique> directory and work there.

  2. Locking for write.

  This can be handled with lock-revision, and actually that is the
  correct way to do it.

The only benefit of using a shared cache is to improve performance by
using "update" when the cache is already primed instead of "get".
However, it is not really obvious if/when that would really improve
responsiveness, because "update" requires more round-trips than "get" if
we keep a cachedrev for every last revision[1].

But if you do that, it would be a good thing to provide facilities to
encapsulate the "location of cache" policy and "portable locking".

[1] The "update cachedrevs on archive-mirror" issue is another issue
that be fixed with metadata, so it would be possible to have a running
cached last revisions w/o keeping cachedrevs for all revisions.


> 2) Storing metadata as revisions is a good idea -- consider recording
>    the metadata in the log messages.
[...]
>    While the "store it all in the log message" pattern isn't
>    universally applicable, I'd bet it works for many specific tasks.
>    This is an example reason why I am skeptical about generic
>    "metadata commands" -- because particular _kinds_ of "metadata" can
>    presumably be optimized in some non-general ways (such as storing
>    it in log messages).

Well... so far that's only two distinct approaches (not necessarily
exclusive) to storing metadata.

And actually there seems to be a need for new commands only for the
"whole tree in cache" solution. I regard "encapsulating location and
locking" enough of a reason to add new commands if the "whole tree in
cache" appears needed. But there is clearly not yet a real need for
that.

Bottom line: yeah, no need for extra commands so far.

-- 
                                                            -- ddaa