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              |
|---------------------------------------|