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]
