-----Messaggio Originale-----
Da: Federico Barbieri <[EMAIL PROTECTED]>
A: Java Apache Mail Server <[EMAIL PROTECTED]>
Data invio: domenica 7 maggio 2000 12.47
Oggetto: Re: Configurability
>
>
> Roberto Lo Giacco wrote:
> >
> > 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!
>
> Ok... having a GUI may be really useful to make Avalon more "popular"
> and I'll be the first using a GUI but this is not the point. Any GUI, no
> matter how smart can reduce verbosity, not complexity. It will allow you
> to draw your wiring with a few clicks but it's not going to tech you
> what wiring Blocks means. So the logic is still in the conf file and its
> patterns. A GUI change only the visualization and the interface but you
> can easily see that any GUI build on a poor logic takes you nowhere.
> That's why I'll keep on working on configuration (as XML) and will care
> later about grafic rapresentation of it.
May be I was too long and verbose to focus my viewpoint: I'm sorry my
english is very poor.
Anyway I'm talking about a simple tool builded on a powerfull XML
configuration: don't take too much time to make XML confs easy to
understand, just point to their power because easyness will be achieved with
the GUI tool.
> Aside of that keep in mind that many people around hates GUI and, even
> if I don't share that feeling, I want them to be able to deal with confs
> using vi.
I hate most GUI tools around and I still use vi and notepad to edit Apache
confs, but I think we need GUI tools if we want to reach a greater target.
> So if you feel an itch 'bout having a GUI you're more than welcomed.
> This whould be a great thing but I belive that strong buildings can only
> grow on strong foundations and so I'll keep on working on confs logic.
Totally agree with you, but what I was saying is building facilities have
nothing to share with strong foundations. Again: point your efforts to have
a powerfull XML conf for power users and leave to a GUI tool the deal to
make things easier for beginners and non-programmers. XML is a metalanguage
and it's not as easy for everyone as we can think: not every computer user
nor network administrator is a programmer!
> > 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
> >
>
> got it. Just a point. a gui tool should handle efficiently
> configurations belonging to more than a machine. If you have two Avalon
> cloned on two PC you probally wnat to be able to change configurations
> once for both. Or you want to keep them separate so you can play on on
> server and let the other as backup. a gui should manage such situations
> well.
>
> Second: Avalon is a Block itself and so it is started and configured
> from the outside (Main.java) that takes care of Avalon lifecycle. It
> will be Avalon loader to manage configs and "commit"
> (changeConfigurations()...) to Avalon.
I'm thinking about a server (so an Avalon block) listening on a port, so it
must be something Main.java starts up and have access to Avalon.java
changeConfigurations()... Am I wrong?
> Again a GUI can be an important score but it seems to me you miss the
> point of current discussions. gui is next step and we're working to make
> current step solid.
I hope to be cleaner this time.
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
