> |------------------------------------------------------------|
> | get/put to cache with group/name/blob-version semantics, |
> | security on transmission, integrity checking, |
> | and reliability of service |
> |------------------------------------------------------------|
>
> ... and the starting point is the bottom layer.
I can agree with starting at the bottom. I think this (above) is about it. I
would like to offer both opaque(blob) version and structured/parsed, but I
do (now) realize that folks need the ability to have the former (as a
starting point).
I've read the Avalon Repository code at:
http://svn.apache.org/repos/asf/avalon/trunk/runtime/repository
and I'm very pleased to see the significant similarities.
I like the clarity/simplicity that Avalon Repository has, but I also like
some of the features that Depot provides (e.g. ability to use java.net.URL
or HttpClient or VFS as environment allows). I do like that we have
Filters/Selectors in common (Depot has Comparators also, 'cos we think order
is possible). I could go on, but not here. Again, I see more in common than
I see in divergence.
I'd be tempted to suggest we import the Repository code into Depot (as a
separate ClassLoader project) and slowly (or quickly) migrate as much into
the Updater project, or use Updater concepts. I think there are interesting
choices to be made, and we could work that merge (over a suitable time) with
some Wiki documentation and/or scheduled group chats. [For example, the
Artifact and (Depot) Resource classes are next to identical, we need to
document what we want, and merge them.]
*If* we can all open our minds (and suppress our egos) sufficiently to allow
this form of merge (without tonnes of blah/blah back and forth on minutiae)
then I think we'd have one heck of a lively/healthy development team
(community), worthy [IMHO] of Apache TLP.
regards,
Adam
