Thanks for your comments. Great feedback.
Dani wrote:
> Scott Dybiec said:
> > This is a tool that I prototyped to determine the feasibility of an
> > Apache module-based GUI, rather than one that is hard coded. Nothing
> > Apache-specific yet, though. There would need to be a corresponding
> > server side configuration tool that could have plug-ins for module,
> > scripts, etc. Thinking about XML for this.
> >
> > Looking for partners in this development.
> >
> > Your thoughts and comments are welcome.
> >
> > $cott
>
> Hi Scott,
>
> It seems rather interesting. I am/have been working in something similar
> with Comanche. I will give you my (constructive :-) feedback
Thanks. And great work with Comanche!
>
>
> I am working in a new (much improved) comanche version that will be presented
> at ApacheCon. I will be releasing some information later this week so you can
> have a feeling of how it is going to look like what Rich will present there
>
> Some of the objectives where:
> a) it should be extensible, so people can write their own modules for
> configuring , say, php or Apache SSL. People who do not use these modules will
> simply unset a check box somewhere and they will not appear
> b) The interface must be programatically designed. I already do something
> (primitive) with the current comanche version, with the .ccf files
> The interface changes acording to these files and to the version of Apache
> running (windows/unix). For the new comanche I take this much further:
> the layout is defined in something somewhat resembling XML (or your JML)
> which is loaded into a tree structure and from there the widgets are created.
> Basically I do the same that you do, but just in <> tags :-)
>
> So what you propose would turn into something like in comanche .ccf:
>
> <ComboBox>
> Name MyComboBox
>
> <ComboItem>
> Name Item1
> Value Papaya
> </ComboItem>
>
> <ComboItem>
> Name Item1
> Value Papaya2
> </ComboItem>
>
> </ComboBox>
>
> With the difference that I will not be describing lists, comboboxes, etc
> but my widgets will be for example ServerName, which will be a widget with
> which you can change the servername in a configuration file
Sounds like you'll have one tag per directive. How will you accomodate new
directives that are part of new modules? Apache's ability to add new modules
dynamically (without recompile) seems really powerful, but accentuates the need
for a very flexible/modular configuration program.
>
>
> People can rearrange the layout or build and new one just changing these new
> new .ccf files and extend the program declaring new widgets like ServerName2,
> etc
>
> Just one doubt:
> As I understand it, JML is used to describe the UI,
> How do you plan to add backend functionality to it?
These ideas are work in progress, but here are my latest thoughts. The server
reads Module Description Files that contains the JML/GTKML description of the
GUI, module directives information (human readable description for help,
argument
types, valid directive contexts). Part of the one for mod_alias might look like
this:
Module "mod_alias"
{
Summary
{
"This module is contained in the mod_alias.c file, and is compiled in by
default. It provides for mapping different parts of the host filesystem in
the the document tree, and for URL redirection.
Directives
* Alias
* AliasMatch
* Redirect
* RedirectMatch
* RedirectTemp
* RedirectPermanent
* ScriptAlias
* ScriptAliasMatch
"
}
Directive "Alias"
{
Argument "url-path"
{
Occurences 1
Type String
}
Argument "directory-filename"
{
Occurences 1
Type Directory
}
Context
{
server-config
virtual-host
}
Override NotApplicable
HelpText
{
"The Alias directive allows documents to be stored in the local
filesystem
other than under the DocumentRoot. URLs with a (%-decoded) path
beginning
with url-path will be mapped to local files beginning with
directory-filename.
Example:
Alias /image /ftp/pub/image
A request for http://myserver/image/foo.gif would cause the server to
return
the file /ftp/pub/image/foo.gif.
Note that if you include a trailing / on the url-path then the server
will
require a trailing / in order to expand the alias. That is, if you use
Alias
/icons/ /usr/local/apache/icons/ then the url /icons will not be
aliased.
See also ScriptAlias."
}
}
Directive "AliasMatch"
{
Argument "regex"
{
Occurences 1
Type String
}
Argument "directory-filename"
{
Occurences 1
Type Directory
}
Context
{
server-config
virtual-host
}
Override NotApplicable
HelpText
{
"This directive is equivalent to Alias, but makes use of standard
regular
expressions, instead of simple prefix matching. The supplied regular
expression is matched against the URL, and if it matches, the server
will
substitute any parenthesized matches into the given string and use it
as
a
filename. For example, to activate the /icons directory one might use:
AliasMatch ^/icons(.*) /usr/local/apache/icons"
}
}
.
.
[A description (GTKML/JML) of the GUI form for displaying/collecting the
above directive/arguments goes here]
.
.
}
>
>
> Finally, if you are interested in programatically implementing UI I would
> strongly recommend you to have a look at TCL/TK (www.scriptics.com)
>
> Best regards
>
> Daniel
Keep kicking butt,
$cott
