Depot layers

2004-06-21 Thread Nicola Ken Barozzi 
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   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

Re: Depot layers

2004-06-21 Thread Stephen McConnell 
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  |
|---|

Re: Depot layers

2004-06-21 Thread Adam R. B. Jack 
 ||
 | 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