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.
open my eyes? I didn't know I had them closed...
> 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?).
I share your vision. As far as "opening my eyes", I recall talking about
this with Federico (what we were referring at JACK: Java Apache
Configuration Kit) long before you were around :)
> 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 totally disagree.
"high powerfull conf file, doesn't matter how much it will be complex"
is the dangerous path that sendmail people have been following for
years.
Also, while they help, GUIs are another form of programming: if the
underlying solution is too complex, WYSIWYG solutions risk to become a
fake and simplified view of what's behind, giving GUI users the taste
"they are missing something".
It has happened to me in every server software I configured: the text
conf files are as close as I can get so they give me total control.
Note: this is not always right, but this is the kind of attitude that
makes GUIs for servers many times unused by system administrators.
The only useful GUI is the one that gives you more than the simple text
files. Not more configurability (that would be wrong), but more help on
programming your server thru configurations and, in the Avalon's case,
pipeline and block building.
> 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.
While I hope to remove the requirement with a conf markup that is
_as_simple_as_possible_, I agree a GUI tool would make a difference.
On the other hand, I would love to see James used _before_ we have a GUI
tool to prove the concept.
> 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!
I have the opposite vision here: conf comes first, GUIs come later to
help.
Sure, no problem in having "future-proof" configuration markup, but
"don't worry about readability, we'll have GUIs anyway" it's the path to
disaster.
> 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.
I'm sure everyone of us has his own vision on how such a tool would
be... on the other hand, please, let's avoid "venting" about "it would
be awesome if..." and do stuff that works.
Not to sound offensive, but overtime you've been very active on the
talking side, but rather inactive on the code-producing side.
Unfortunately, turing machines require code not talks to do their job.
I won't comment further proposals that are not backed up with code to
prove them. This is a general pattern I learned to pursue, in fact,
Avalon/James do not have the community they deserve because of ideas
without code to enforce them.
Our thanks should go to both Federico and Serge for making possible to
talk about "real things that work" :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
