You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@depot.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2004/06/21 20:11:50 UTC
Depot layers
Depot should be a layered system to be scalable, both code and community
wise.
Here is how it's thought at the moment:
--------------
| update |
--------------
| version |
--------------
This is how it could evolve:
--------------
| classloading |
--------------
| update |
--------------
| version |
--------------
There are also other utilities thought of ATM, like license checker and
installer, but thery are still in the air.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Depot layers
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> |------------------------------------------------------------|
> | 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
Re: Depot layers
Posted by Stephen McConnell <mc...@apache.org>.
How about ...
|------------------------------------------------------------|
| secure, operational, trusted artifact and classloader |
| management |
|------------------------------------------------------------|
| version management |
|------------------------------------------------------------|
| get/put to repository with support for validation of |
| repository content, policies concerning trust and level of |
| confidence (e.g. I trust Apache, I don't trust SF) - also |
| at this level is the repository implementation strategy - |
| e.g. file system, LDAP store, etc. created using |
| classloader meta data |
|------------------------------------------------------------|
| meta data model for staged classloader definitions, |
| criteria and defaults management |
|------------------------------------------------------------|
| 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.
Steve.
Nicola Ken Barozzi wrote:
>
> Depot should be a layered system to be scalable, both code and community
> wise.
>
> Here is how it's thought at the moment:
>
> --------------
> | update |
> --------------
> | version |
> --------------
>
> This is how it could evolve:
>
> --------------
> | classloading |
> --------------
> | update |
> --------------
> | version |
> --------------
>
> There are also other utilities thought of ATM, like license checker and
> installer, but thery are still in the air.
>
--
|---------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org |
|---------------------------------------|