[darcs-users] darcs-hs/hashed-storage review
nicolas.pouillard at gmail.com
Thu Aug 6 10:11:23 UTC 2009
Excerpts from Ganesh Sittampalam's message of Thu Aug 06 01:37:22 +0200 2009:
> On Wed, 5 Aug 2009, Petr Rockai wrote:
> > Ganesh Sittampalam <ganesh at earth.li> writes:
> > > My most important question is about the dividing line between
> > > hashed-storage and darcs-hs. The biggest weakness of hashed-storage as
> > > a separate package is that it has functions that are specific to Darcs
> > > repositories. To my mind, it either needs to abandon this knowledge,
> > > perhaps by abstracting it over a typeclass that is meaningful in
> > > itself, or some or all of hashed-storage needs to move into the darcs
> > > tree proper. Otherwise, changes to some parts of darcs will continue
> > > to require lockstep changes to hashed-storage - which is ok when Petr
> > > is developing the two together intensively on his own, but not really
> > > when other people are involved or over a longer timeframe. One option
> > > would be to move it all into the darcs tree but distribute it as a
> > > separate cabal package with a more darcs-specific name.
> > Well, I have done a bunch of work on separating the darcs-specific bits.
> > For now, they live in the library, because they are an important testing
> > resource. However, out of Storage.Hashed.Darcs, there are only a few
> > darcs-specific bits living in Storage.Hashed. It also seems that
> > abstracting the darcs-specific bits is workable.
> > I however expect this to be useful outside of darcs proper as well. The
> > lock-step development is a problem, but I am not sure how much it can be
> > eliminated. Probably something for further discussion.
> I guess the question is what the intended use cases for hashed-storage
> outside darcs are. I can see two possibilities:
> (a) General hash-structured storage library. It feels like it should be
> generally useful but the only concrete idea I can think of would be for
> reading git repos. In this situation hashed-storage really does belong as
> an independent library.
> (b) A way of reading darcs repos (and perhaps writing them, for the
> brave). This would be an important step towards a stable darcs API, and
> clearly should be a separate cabal package, but if it's just that, I think
> it should be called something darcs-specific (darcs-storage?) and live in
> the darcs tree.
Or writing a program that needs massive persistent data, like a mail client.
I'm planning to use this kind of library one day for a program like this,
however maybe hashed-storage would have to be more flexible.
More information about the darcs-users