I red all your proposals for configuration trees and I wish to expose my
personal view of the fact hoping to open your eyes.
I think our work is target to everyone on the net who was to run a Mail
Server, from the best unix hacker which can write two hunderds lines of 8086
assembly code to the young guy who never seen a non GUI interface. If I'm
right I think we can have only a single, simple, silly solution for our
configurations dilemma: make up a GUI for the Avalon Framework!
I know I proposed it on the Avalon mailing list promising to get out
something from the cilinder in short time, but I was really busy with
University and work: I beg your pardon.
My approach to the problem is: if someone want's to have full control on the
configurations can do it on himself putting his hands into complex and high
configurable XML files, but who doesn't need such power (most end-users) or
who simply hates conf files and start crying whenever meet an ASCII/XML
configuration (most windows users) can use our simple, easy, remote
configuration tool (may be an applet?).
In such view I think we need to have a really high powerfull conf file,
doesn't matter how much it will be complex because most users will use the
tool to make silly stuffs like redirecting an email, forwarding, starting up
a mailing list, or such well defined things. But whenever someone needs to
make a non commong thing (like reparsing an e-mail to replace any Micro$oft
occurence with ****) he can do it on himself.
I really think a simple GUI tool to configure anything under the Avalon
framework, from the builded-in tools like the logger to external components
like James, is strongly required and can make the difference. I really think
if we make this stuff everyone will use pur framework for it's purposes
because it make things really easier: and they have a powerfull
configuration tool ready!
The view I have in my mind about that tool is a client/server application
with a well know (reconfigurable for security) port where the Avalon is
listening for connections (simply TCP/IP authentication required based upon
addresses, domains, login, and even secret key).
Once the connection is established the server side will make changes based
on the Objects sent on the network by the client.
On the client side you have a tree representing all Blocks in the framework
and for each node yu can define all general infos (defined for every node)
allowing each node to PUT into the tool (through a way like Bean class does)
private configurations extensions (for James can be a table of rules or
somethings which can simply represent it's XML conf tree).
So we have a two pane window with a tree in the left side and a tabbed pane
in the right side.
I hope you catch my sight.
Roberto
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
