At 11:20 15/3/01 -0000, Rob Walker wrote:
>Looked at the 3.1a1 distribution, and starting to get my head around
>it. Some nice features and concepts ... good work!
>
>Not sure how some of the areas we need for our environment fit
>into the current structure or future plans e.g.
kewl ...
>* Dynamic applications/components - the concept of "long running"
>VM sessions into which we dynamically load and unload
>components and applications. At startup all we have is an "empty
>shell" and the ability to request loads. Classes would get unloaded
>when dead to prevent memory hogging over time.
>
>* Dynamic remote machine deployment - the concept of a pool of
>host machines with minimal software installed (e.g. the JAVA VM
>and a Bootstrap Loader). Ideally we'd remotely deploy initially the
>Execution Environment (e.g. Avalon/Phoenix) and then once
>running specific components and applications.
Both of these points *should* be doable (ie it has been designed to be done
this way) however it requires some sort of management interface be built on
top of the Phoenix kernel. At the moment the class (Main.class) that starts
the kernel also deploys the Applications. If the management interface was
implemented the Applications could be deployed at anytime.
>* Cross VM pooling - allow applications/components to be
>distributed across VM's and machines, with ways for them to be
>accessed and use in a "single image" manner e.g. via directory
>services, proxies etc.
Berin talked about this a while ago - however I don't see how it fits in
with Phoenixs notion of Blocks. In these cases the Blocks would be proxies
to the "real" Blocks that were distributed between servers. This would be
technically easy to implement by mods of the BlockFactory (maybe doable in
3-4 hours once you understand Avalon/Phoenix) but I am not sure what
advantage it would bring ;) Personally I see Avalon as lower level than
that and would thus programtically add in distribution rather than automate
it.
>* Application and Component caching - to allow a component to be
>rebuilt and redeployed, without knocking out running versions until a
>control/sync point is determined.
To a degree it would be possible. We could run the
contextualize/compose/configure phases of 2 instances of applications.
However because init() will do things like bind to ports it would not be
possible to go that step further. There is no plan yet to do anything like
this though.
>* Multiple application/component instances - a single component or
>application being loaded once, but having instances to meet
>demand (either for reasons of volume or partitioning).
How do you determine demand/volume ? I think in most cases this is a higher
level concept. Especially as it is not possible to run some Applications
(ie two webservers) simultaneously.
>* Locally silent operation - minimal logging to the local file system
>(apart from crisis, panic or debug logs). Other logging being via a
>flexible "log connector" approach so that log output can be gathered
>centrally/remotely.
trivial to implement. However currently the Phoenix logging is more
orientated to developer rather than admin and this should be cleaned up
first. (It is top on my TODO list but incredibly boring ...).
>Feel free to ignore or disregard if these are seen as outside the
>scope of Avalon and Phoenix.
The scope of Phoenix/Avalon is determined by it's users/developers ... ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
