At 02:44 16/4/01 +0200, Stephen McConnell wrote:
>I'm not at all sure if this is answering your question - but the following
>it a little summary of our experience to-date. Firstly, the idea above to
>have configuration files per block will be a big plus.
Actually I wasn't proposing that exactly ;) I was actually just proposing
that config be in a separate file ;) We could still do a block per file I
guess by having something like
<!DOCTYPE project
[
<!ENTITY block1 SYSTEM "block1.xml">
<!ENTITY block2 SYSTEM "block2.xml">
]>
<configuration>
&block1;
&block2;
&block3;
</configuration>
>Our current server
>assembly.xml file is currently about 1,500 lines. There are a few things
>that could improve manageability of the content:
>
> 1. Ant style properties, i.e. the ability to define
> a single property and have that property propagated
> across several block configurations
We talked about adding constants with respect to Berins proposal but as we
never got around to that it never got implemented ;) It is especially
painful when you have to copy the same property into multiple places (ie
dns name for HELO message, interface to be bound to etc ...).
> 2. The ability for one configuration file to extend
> another. The reason for this is that some aspects
> of our configuration are great for developers who
> want to extend the platform, other aspects are more
> oriented towards the declaration of company policy.
Will Normal XML Entity level includes suffice (like above) or how about
something more? The only *clean* way of doing it was with something like
XSL which I am a little hesitant to implement at the moment.
>Beyond the question of how configuration information is managed, I seem to
>remember an email a while ago that was discussing the need to "unpack" the
>.sar file. Aside from configuration info, is there a necessity to unpack
>jar and bar files
in some servers yes ... some may include other stuff in .sar other than
code/config. (Say web-pages for web-server). How we do it is another
question ;)
>i.e. is it possible to load these resources from the .sar file directly.
yep.
>If this is possible it would eliminate some level of
>complexity simply through not exposing what is happening at the file system
>level.
agreed.
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]
