Re: [Gnu-arch-users] Re: arch with 'special files'

[Jan Hudec]

On Thu, Apr 07, 2005 at 09:39:40 -0700, Josh England wrote:
> Jan Hudec wrote:
> > On Wed, Apr 06, 2005 at 13:36:14 -0700, Tom Lord wrote:
> > 
> >>   > A single 'second-order' metadata string would basically give infinite
> >>   > flexibility in terms of metadata. [...] would
> >>   > allow any number of creative facilities to be built on top of it.
> >>
> >>A unique fixed string per file would have the same effect and we
> >>already have one of those.
> 
> I understand what you're getting at.  One could archive their own
> metadata file(s) indexed by the file ID, then manage the metadata in
> surrounding wrappers.  This actually does effectievly allow generic
> metadata to be created.  Perhaps explicitly adding it to arch is not
> necessary.  Maybe just detailing how this could work in the
> documentation would be enough.
> 
> However, providing a fast/formal/consistent indexing method would also
> be nice, that way the metadata is always in the same place instead of
> being different in every archive.  A fast indexer could effeciently be
> used to power a 'tla get-changed-metadata' command to return a list of
> all files with changed metadata.  Then, 'tla get-metadata <file-id>' and
> 'tla set-metadata <file-id> <meta-string | meta-file>' or some such
> could be used to get/set the actual metadata per file-id.
> I think this might be converging on something that doesn't suck.
> 
> > Yes, but we need one more -- the id must not change throughtout life of
> > the file, while other metadata may need to change. So we need an id and
> > another string. That is two strings so we can as well have N strings
> > (we'd need a _standard_ way to mangle N attributes in it anyway).
> > 
> > They should probably live somewhere in {arch}, indexed by file id's.
> > 
> > We calso need a way of passing them into a hook to process them. There
> > should be one hook when preparing a changeset (so it can synchronize
> > with attributes saved by some other means) and one when applying
> > a changeset (so it can apply them).
> 
> In looking at Monotone, they seem to have the ability to call per-file
> metadata hooks:
> 
> http://www.venge.net/monotone/docs/File-Attributes.html#File-Attributes
> 
> This kind of thing probably wouldn't be too hard to add in to the
> proposed solution above...

... seems dead simple. Yes, I feel I like that way. What we need to make
it actually useful in the real world is:

1) Define standard location for the index. Something like
       {arch}/=metadata
   (I *dont* like the naming scheme, but all prefixeless names are
    currently reserved for categories.)
2) Define better interface for hooks. I don't think the current
   interface -- one hook called with different parameters -- is right.
   We would need something where it would be easier to install hook for
   an action provided by someone, without touching all the others.
   I'd suggest calling the metadata hooks as:

       .arch-params/hooks/metadata.$metadatum $action <<EOF
       metadatum-value filename
       ...
       EOF

   where $metadatum is name of the metadatum, $action is apply or diff
   and the value for each file (for which it is specified) is on
   standard input. The 'diff' action returns a list of new values for
   whichever files it wishes (ie. even ones that are not mentioned in
   the input) and the metadata file should be updated.

   Updating that file implies, that the file format must be specified
   too. It would be perhaps:
   file-id metadatum-name metadatum-value
   (this way ordering is unimportant).

Just an idea.

-------------------------------------------------------------------------------
                                                 Jan 'Bulb' Hudec 
<address@hidden>

signature.asc
Description: Digital signature