[Gnu-arch-users] decoupling pfs/archive-pfs and the archive format

[Johannes Berg]

I've been looking through the code in archive-pfs, archive-version and
the like because I wanted to implement a new archive format that is
accessed over pfs just like the old one. Basically, the abstraction is
there but so far tla always calls archive-pfs.
tla--archd can decide whether to use archive-pfs or archive-archd based
on the archive URI, but something that is using pfs cannot. So I was
thinking it might be desirable to have tla based on the
".archive-version" file which archive-XY layer to use.

Basically, I'm thinking this:
 * if the archive URI is accessed via pfs, tla gets the .archive-version
 * then, based on the contents, it creates an instance of archive-XY,
   similar to how the pfs code handles things.
  Example:
   hackerlab-version1: instantiate archive-pfs with the readonly flag on
   hackerlab-version2: instantiate archive-pfs normally
   my-foobar-version1: instantiate archive-foo

My idea is to decouple the archive implementation and the pfs layer so I
can implement a new archive format that is also just accessed via pfs.

* Required changes
 - arch_make_archive needs a new parameter to be able to create the
   correct archive abstraction. Instead of calling arch_pfs_make_archive
   it would then call arch_XY_make_archive
 - arch_archive_connect_location needs to first decide on the URI which
   access layer to use ("arch://" uses archive-archd, pfs uses pfs)
   and at that point it either has an arch-handle (archive-archd) or it
   reads -- through the correct pfs layer -- the ".archive-version" file
   and asks all arch- layers if they can process an archive with that
   version.
 - some moving functions, not much really

The base changes would just be framework, but on top of that I'd be
interested in implementing an encrypted archive format (actually, I
already have a plan). It just seems wrong to implement it on top of
archive-pfs, so I'm thinking decoupling pfs and archive-pfs would be a
good thing.

Comments?

johannes
-- 
http://www.sipsolutions.de/
Key-ID: 9AB78CA5 Johannes Martin Berg <address@hidden>

signature.asc
Description: This is a digitally signed message part