config4gnu-developer — Config4GNU developers list

Re: [Config4gnu-developer] I was thinking of a similar project...

[Justin Y. <ju...@sk...>]

Damien,

Thanks for your interest in CFG.  Below are my responses to your ideas/questions.

On Fri, 4 Jul 2003 00:49:34 +0930
Damien Uern <car...@op...> wrote:

> Goals that differed:
> 
> 1) Highly portable so that other systems such as BSD/Solaris could use
> it.

We'd like to have it highly portable as well.  Currently, it depends only on Xerces-C++ and perl for core things, GTK-- for GUI front end, and PHP for the web front end.  The core system is fully usable w/o the GTK and PHP front ends, you're welcome to write something in what you'd feel is more portable using our API.  Its worth pointing out that if you look at the mailing list archives (it seems they're claiming to be "not yet archived" at the moment...), you'll see someone had success I believe with compiling it under Solaris.
 
> 2) Default configuration format NOT based on XML, but rather something
> similar to the Win INI format with the ability to nest groups. I
> wanted to do this because I don't believe XML is very readable and I
> want old-hat Unix types to be able to simply use vi to edit config
> files without much bother (thus increasing acceptance, even among the
> BSD's).

You're misunderstanding our system.  The beauty is that existing formats stay in their current format, there is no "default" format.  You have to pick one.  You're welcome to just use XML, but we don't necessarily recommend it.  When a config file is loaded, it is parsed into and out of an XML data structure on the fly as needed.  If we didn't tell you, you wouldn't know it used XML if you're an end user.  It takes under 100 lines of perl to create a parser for your own configuration format, so you can invent a new one if you like. :)

> 3) Only the GUI-Layout file would be XML based. It would describe all
> possible variables that can be changed in the program, including their
> types (bool, String, etc).

All of the "meta-data" is in XML for simplicity (not having to design another config format) and ease of use because our GUIs let you edit XML.  It could easily be stored in another format and converted using one of our parsers, but right now we just use XML.

> 4) Initially the library would only provide a way for applications to
> open config files without actually having to know where they were. The
> library would  find and cache the path to the config file similar to
> how the linker does.

Thats what we can do, among other things.  Its all configured in the main XML file.

> 5) Small and fast, written in C/Flex/Bison, without dependence on
> other libraries or languages.

You'd be surprised how quick our stuff is.  My box is a celeron 366 and it it takes 1-2 seconds the first time it parses and loads a config file (which are loaded on-demand).  With proper caching, there'd be no delay after the inital load.  
 
> 6) Try to encourage developers to move their configurations over to
> the new system. Submit patches to projects like Samba to try and
> encourage this.

We've thought about this and decided to start doing so once we're at a stable 1.0 or 1.0beta stage.  We're not quite there, although our system is fully functional and can edit many config formats.  It supports samba nearly fully, but we've got some more advanced features we want to incorporate before we dub it as ready for public use.
 
> Even some of those may overlap with your goals. In case it's useful, I
> have attached an (edited) email that I sent to my local LUG's mailing
> list that described what I wanted.
> 
> Cheers,
> 
> Damien
> 
> --
> Postgraduate Student(Electrical and Electronic Engineering)
> The Flinders University of South Australia
> 
> ------------------
> 
> <SNIP>
> 
> The most important objective is a structured and logical /etc
> directory with a single unified configuration file format. I have
> decided that being able to display said configuration files in a GUI
> is secondary and in fact I want to have a separate "layout" file so as
> to offer the GUI more flexibility and power without destroying the
> readability of the config file format. I think having a unified config
> file format and logical directory structure greatly simplifies writing
> a GUI program for configuring the system anyway, so we get that added
> benefit for free.
> 
> Simple configuration files and scripts need not be altered in this new
> system, e.g. "hosts, hosts.allow, etc" should be able to keep their
> current format because it is so simple (and maybe we should leave
> "termcap" the hell alone :). A program parsing the /etc tree will
> ignore such special files (and any other files that don't appear to be
> of the correct format).
> 
> <SNIP>
> 
> So here are my revised goals:
> 
> 1. Design a logical directory structure within the /etc directory.
>    - it must be fairly simple for somebody to look through that
>    directory to 
> find something without resorting to "locate" or "find".
> 2. Design a unified configuration file format.
>   - This format must be simple enough to be easily understood by
>   somebody 
> without them having to refer to a manual (by referring to a manual, I
> mean a manual describing the syntax, not the configuration options
> presented within).
>   - All configuration files will have a common extension so they can
>   easily be 
> seen as such (e.g: .conf).
> 3. Design a simple (probably xml-based) layout file that allows an
> application to display (graphically) the configuration options for a
> program.
>   - The file format should be fairly easy to understand, but referring
>   to a 
> manual in order to write one will be necessary (and possibly to read
> one and understand it fully).
>   - It should allow some interpretation by the GUI program so that all
>   
> configuration dialogs look consistent. The layout file shouldn't
> specify things like "rectangle,200,200", but should just group
> configuration variables and specify the type of value they take (like
> in a programming language), amongst other things (such as a "display
> name", visibility, etc etc). 
>     - The reason for these layout files is so that packages can
>     describe 
> enough about their configuration options to allow it to be displayed 
> graphically without the graphical application having to specifically
> know about said software package.
> 
> I believe something like this could be done if it is managed in
> stages:
> 
> 1) Discourage hard-coding paths to configuration files so that
> configuration files can be placed wherever the user pleases.
> Application accesses these files through a library "say libetc, or
> libconfig".
>   - Devise a fast-lookup method for finding the configuration files
>   fast by 
> using a cache and/or a pre-defined filepath and/or some other means
> (similar to how the linker looks up library files).
>   - At this stage applications can keep their own configuration file
>   formats 
> and must parse the file themselves. However, the naming of these files
> and their location can now be controlled without breaking the
> application.
> 
> 2) Devise configuration file format and create a parser and API for
> this format for applications to use. This functionality becomes part
> of the existing library as created in step 1.
>  - Encourage people to use the library if they can and to file feature
>  
> requests if they cant.
> 
> 3) Create layout file format and sample application that can parse the
> etc tree and provide a GUI for config files that have an accompanying
> layout file.
> - Enourage people to package layout files as part of their software 
> distribution so as to ease administration.
> 
> <SNIP>
> 
> Somewhere in those stages the layout of the /etc directory and the
> format of the configuration/layout files should be attempted to be
> made a standard (LSB) so as to encourage people to follow it.
> 
> For all those that say "the current system is fine once you know it",
> I say how does that make the current system the best possible? How can
> we make progress if we stay stationary? (and if you say "if it aint
> broke don't fix it", I'm going to scream :) It *IS* broke :)
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
> _______________________________________________
> Config4gnu-developer mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/config4gnu-developer
> 
> 


-- 
SkiingYAC
Custom Solutions
http://www.SkiingYAC.com

[Config4gnu-developer] I was thinking of a similar project...

[Damien U. <car...@op...>]

Hi,

Just a few days ago I was thinking about how bad the configuration system in 
/etc is (i.e. files strewn all over the place). I was having a discussion on 
the mailing list of my local LUG about this and I came up with what I thought 
would be a really good solution. Just before I started writing some design 
documentation on this idea, I thought I would research what had already been 
done and I stumbled upon your website.

Well! Your project has very similar goals (mostly identical) to what I had 
intended, no point starting another project. My ideas did differ from yours 
in some ways, so I would like to offer those differences here.

Goals that differed:

1) Highly portable so that other systems such as BSD/Solaris could use it.

2) Default configuration format NOT based on XML, but rather something similar 
to the Win INI format with the ability to nest groups. I wanted to do this 
because I don't believe XML is very readable and I want old-hat Unix types to 
be able to simply use vi to edit config files without much bother (thus 
increasing acceptance, even among the BSD's).

3) Only the GUI-Layout file would be XML based. It would describe all possible 
variables that can be changed in the program, including their types (bool, 
String, etc).

4) Initially the library would only provide a way for applications to open 
config files without actually having to know where they were. The library 
would  find and cache the path to the config file similar to how the linker 
does.

5) Small and fast, written in C/Flex/Bison, without dependence on other 
libraries or languages.

6) Try to encourage developers to move their configurations over to the new 
system. Submit patches to projects like Samba to try and encourage this.

Even some of those may overlap with your goals. In case it's useful, I have 
attached an (edited) email that I sent to my local LUG's mailing list that 
described what I wanted.

Cheers,

Damien

--
Postgraduate Student(Electrical and Electronic Engineering)
The Flinders University of South Australia

------------------

<SNIP>

The most important objective is a structured and logical /etc directory with a 
single unified configuration file format. I have decided that being able to 
display said configuration files in a GUI is secondary and in fact I want to 
have a separate "layout" file so as to offer the GUI more flexibility and 
power without destroying the readability of the config file format. I think 
having a unified config file format and logical directory structure greatly 
simplifies writing a GUI program for configuring the system anyway, so we get 
that added benefit for free.

Simple configuration files and scripts need not be altered in this new system, 
e.g. "hosts, hosts.allow, etc" should be able to keep their current format 
because it is so simple (and maybe we should leave "termcap" the hell alone 
:). A program parsing the /etc tree will ignore such special files (and any 
other files that don't appear to be of the correct format).

<SNIP>

So here are my revised goals:

1. Design a logical directory structure within the /etc directory.
   - it must be fairly simple for somebody to look through that directory to 
find something without resorting to "locate" or "find".
2. Design a unified configuration file format.
  - This format must be simple enough to be easily understood by somebody 
without them having to refer to a manual (by referring to a manual, I mean a 
manual describing the syntax, not the configuration options presented 
within).
  - All configuration files will have a common extension so they can easily be 
seen as such (e.g: .conf).
3. Design a simple (probably xml-based) layout file that allows an application 
to display (graphically) the configuration options for a program.
  - The file format should be fairly easy to understand, but referring to a 
manual in order to write one will be necessary (and possibly to read one and 
understand it fully).
  - It should allow some interpretation by the GUI program so that all 
configuration dialogs look consistent. The layout file shouldn't specify 
things like "rectangle,200,200", but should just group configuration 
variables and specify the type of value they take (like in a programming 
language), amongst other things (such as a "display name", visibility, etc 
etc). 
    - The reason for these layout files is so that packages can describe 
enough about their configuration options to allow it to be displayed 
graphically without the graphical application having to specifically know 
about said software package.

I believe something like this could be done if it is managed in stages:

1) Discourage hard-coding paths to configuration files so that configuration 
files can be placed wherever the user pleases. Application accesses these 
files through a library "say libetc, or libconfig".
  - Devise a fast-lookup method for finding the configuration files fast by 
using a cache and/or a pre-defined filepath and/or some other means (similar 
to how the linker looks up library files).
  - At this stage applications can keep their own configuration file formats 
and must parse the file themselves. However, the naming of these files and 
their location can now be controlled without breaking the application.

2) Devise configuration file format and create a parser and API for this 
format for applications to use. This functionality becomes part of the 
existing library as created in step 1.
 - Encourage people to use the library if they can and to file feature 
requests if they cant.

3) Create layout file format and sample application that can parse the etc 
tree and provide a GUI for config files that have an accompanying layout 
file.
- Enourage people to package layout files as part of their software 
distribution so as to ease administration.

<SNIP>

Somewhere in those stages the layout of the /etc directory and the format of 
the configuration/layout files should be attempted to be made a standard 
(LSB) so as to encourage people to follow it.

For all those that say "the current system is fine once you know it", I say 
how does that make the current system the best possible? How can we make 
progress if we stay stationary? (and if you say "if it aint broke don't fix 
it", I'm going to scream :) It *IS* broke :)

[Config4gnu-developer] apache2 parser status

[Justin Y. <ju...@sk...>]

I've committed the changes for the apache2 parser.  Right now it will probably not be able to actually parse most apache 1.x/2.x config files because most include other files, which currently is not working because apache supports a few things that we currently don't:

- including directories
- including w/ wildcard(s) in path
- relative paths

It also seems that apache 1.x has a few directives which 2.x doesn't, and probably the converse is true as well.  It may take some time to get all the differences sorted out.  

I think the big priority would be to get the including to work and get it to load and recognize most of the 1.x directives.  Ideally we should probably have 2 separate parsers w/ different typedefs.  Only downside is that the apache2 typedef is currently about a half a meg, so we could start eating up a lot of memory w/ both of them...  I can't imagine what it would be like with multiple languages in it...  

For the includes, the relative path thing should be fairly easy.  The other two both involve handling the inclusion of multiple files with one include directive, which is a little messy.  I think it might be easiest to create a single include node for the actual directive, and then the "sub-parser" would detect whether the path could match more than 1 file, in which case it would enclose each file in another level or markers, i.e.:

<!-- actual directive -->
<include>
	<value>conf/modules.d/*conf</value>
</include>
<include real=false> 
	<value>conf/modules.d/file1.conf</value>
</include>
...
<fileend>
	<value>conf/modules.d/file1.conf</value>
</fileend>
<include real=false>
	<value>conf/modules.d/file2.conf</value>
</include>
...
<fileend>
	<value>conf/modules.d/file2.conf</value>
</fileend>
...
<fileend>
	<vale>conf/modules.d/*conf</value>
</fileend>


I think this would allow everything to be kept track of without over-complicating things.


Just to document and share some things me & Jason have discussed recently, we also still have no support for "Transparent containers" like IfDefine and IfModule, which, if the test associated with them is true, allow directives enclosed in them to be treated  (and therefor addressed) as if they were at the same level as the IfDefine/IfModule.  We think the directives need to be contained inside some sort of container, but then some parts of the code will need to be re-written to properly address and handle them.

Also, we talked about how for apache the UI needs to get something other than the tag used in the XML or the "name" of the directive.  For example, the UI's currently display "Directory" in the tree for all "Directory" directives.  We want to be able to display the path associated with each Directory (and similar) directive, so that the UI would show "Directory /var/www/htdocs/bob" instead, which is much more informative.

Justin

-- 
SkiingYAC
Custom Solutions
http://www.SkiingYAC.com

Re: [Config4gnu-developer] enumerated types for Apache

[Jason L. <jl...@me...>]

There is no implementation for enumerated types. The tags you see in the
samba-config.xml file were just chicken scratch, to demonstrate how they
might be defined. Feel free to make modifications...

Actually, there is a sort of implementation of enumerated types. In the form
definition file, you can specify a "select1" tag and specify in it what
values should appear in the drop down box. However, a true enumerated type
will have the possible values listed in the type definition file and will
restrict entry to those values.

Jason



>>> ju...@sk... 04/29/03 12:16 PM >>>
I'm looking at samba.xml and I see the <enum-item> and <alt-itemname> tags
being used for the YesNoAuto type, along with a <default> tag.  A few
questions before I finish up the apache type definition xslt:

Is the <default> required, or is that only used if the actual property
itself has no default?

Most of the enumerated things apache has a On|Off|Default, what is the
proper combination of things I need to do to get On|Off to show up instead
of the true/false?  Since they're not treated as "boolean", I guess I just
do:

<enum-item>On</enum-item>
<enum-item>Off</enum-item>
<enum-item>Default</enum-item>

Is that correct or do I need to incorporate that On = true and Off = false?

Justin

-- 
SkiingYAC
Custom Solutions
http://www.SkiingYAC.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Config4gnu-developer mailing list
Con...@li...
https://lists.sourceforge.net/lists/listinfo/config4gnu-developer

[Config4gnu-developer] enumerated types for Apache

[Justin Y. <ju...@sk...>]

I'm looking at samba.xml and I see the <enum-item> and <alt-itemname> tags being used for the YesNoAuto type, along with a <default> tag.  A few questions before I finish up the apache type definition xslt:

Is the <default> required, or is that only used if the actual property itself has no default?

Most of the enumerated things apache has a On|Off|Default, what is the proper combination of things I need to do to get On|Off to show up instead of the true/false?  Since they're not treated as "boolean", I guess I just do:

<enum-item>On</enum-item>
<enum-item>Off</enum-item>
<enum-item>Default</enum-item>

Is that correct or do I need to incorporate that On = true and Off = false?

Justin

-- 
SkiingYAC
Custom Solutions
http://www.SkiingYAC.com

[Config4gnu-developer] Changes to Config4GNU's type system

[Jason L. <jl...@me...>]

Tonight I am committing some rather extensive changes to the way Config4GNU
does types.

Config4GNU defines a number of built-in types. Previously, these types were
just referred to by their names, just as any other types. The new changes
will require builtin types to be identified with a special "builtin:"
prefix. So, i.e. wherever you have type="SingleLineString" must now become
type="builtin:SingleLineString." My commit includes updates to the Samba
type definition file.

What you should now be able to do is cross-reference types from multiple
type definition files. The prefix of a type name (the part before the colon)
becomes the name of the type definition file (without the .xml suffix). The
part after the colon becomes the name of the type inside the type definition
file.

So, in samba-config.xml you should be able to create a type that extends
"ini-section" from the ini-style.xml type definition file.
e.g.
<type name="samba-share">
  <extend type="ini-style:ini-section"/>
</type>

When you use a type from the same file it is defined in, you can omit the
prefix. This provides some backwards compatibility and saves some typing.

~Jason

Re: [Config4gnu-developer] initial Apache parser checked in

[Justin Y. <ju...@sk...>]

On Tue, 22 Apr 2003 13:48:09 -0400
"Jason Long" <jl...@me...> wrote:

> Justin,
> 
> get_value() and set_value() assume that it is a single-valued
> property, so they should produce an error if used on an object that
> supports multiple values.

My question though is do we really want to iterate through all of the possible children and check to make sure only 1 is of type value?  Previously, this was done by checking the cardinality of the "value" property, which doesn't work anymore.  Maybe they should just keep searching by the tag "value" and we enforce the convention that if you only have 1 value, then you use the tag "vale"?

> Perhaps for get_property_objects, we could create a new method called
> get_children_of_type(Type) that allows you to specify a type and
> returns all children objects that are members of that type.
> 
> Or, we could just overload the get_property_objects to allow you to
> specify a type argument instead of a tag name.

I was thinking of overloading it...

> I'm not sure whether get_property_definition() needs changed at this
> point... is there a specific place it's being used that is going to
> break?

Line 50 of ElementBackendObject.cc uses it for has_value.  Apparently it is already returning false if multi-valued, so if we amend the previous  convention above and say that if you've got only 1 value you MUST use the tag "value" and if you've got more than 1 value you CANNOT use the tag value then it wouldn't be a problem.  Otherwise we'll have to iterate until we find something of type value, and iterate through everything to make sure there's only 1...  There may be a better solution though.


Additionally, I've been looking at apache's documentation, and it seems that at least for 2.x, apache is using a convenient XML format to document all of its directives, and it shouldn't be hard to translate.  While they break their stuff down into separate files for each module, I think I'm just going to concatenate everything together into 1 huge file, unless you can think of a reason not to (I haven't been able to come up with one).

Justin


> 
> 
> >>> ju...@sk... 04/22/03 13:41 PM >>>
> Jason,
> 
> How should we translate the get_property_definition("value"),
> get_property_objects("value") and get_value/set_value/etc calls in
> ElementBackendObject?  I guess in theory some of those calls won't be
> used for multi-valued things.  The best solution is probably to have
> them instead search for things of type CfgBuiltin::VALUE, but that
> gives the possibility of multiple hits.  Should we just return the
> first for get_value/set_value/etc w/ a warning on stderr, or do you
> have a different suggestion?
> 
> Justin
> 
> 
> 


-- 
SkiingYAC
Custom Solutions
http://www.SkiingYAC.com

Re: [Config4gnu-developer] initial Apache parser checked in

[Jason L. <jl...@me...>]

Justin,

get_value() and set_value() assume that it is a single-valued property, so
they should produce an error if used on an object that supports multiple
values.

Perhaps for get_property_objects, we could create a new method called
get_children_of_type(Type) that allows you to specify a type and returns all
children objects that are members of that type.

Or, we could just overload the get_property_objects to allow you to specify
a type argument instead of a tag name.

I'm not sure whether get_property_definition() needs changed at this
point... is there a specific place it's being used that is going to break?

Jason



>>> ju...@sk... 04/22/03 13:41 PM >>>
Jason,

How should we translate the get_property_definition("value"),
get_property_objects("value") and get_value/set_value/etc calls in
ElementBackendObject?  I guess in theory some of those calls won't be used
for multi-valued things.  The best solution is probably to have them instead
search for things of type CfgBuiltin::VALUE, but that gives the possibility
of multiple hits.  Should we just return the first for
get_value/set_value/etc w/ a warning on stderr, or do you have a different
suggestion?

Justin

Re: [Config4gnu-developer] initial Apache parser checked in

[Jason L. <jl...@me...>]

Justin,

get_value() and set_value() assume that it is a single-valued property, so
they should produce an error if used on an object that supports multiple
values.

Perhaps for get_property_objects, we could create a new method called
get_children_of_type(Type) that allows you to specify a type and returns all
children objects that are members of that type.

Or, we could just overload the get_property_objects to allow you to specify
a type argument instead of a tag name.

I'm not sure whether get_property_definition() needs changed at this
point... is there a specific place it's being used that is going to break?

Jason



>>> ju...@sk... 04/22/03 13:41 PM >>>
Jason,

How should we translate the get_property_definition("value"),
get_property_objects("value") and get_value/set_value/etc calls in
ElementBackendObject?  I guess in theory some of those calls won't be used
for multi-valued things.  The best solution is probably to have them instead
search for things of type CfgBuiltin::VALUE, but that gives the possibility
of multiple hits.  Should we just return the first for
get_value/set_value/etc w/ a warning on stderr, or do you have a different
suggestion?

Justin

Re: [Config4gnu-developer] initial Apache parser checked in

[Justin Y. <ju...@sk...>]

Jason,

How should we translate the get_property_definition("value"), get_property_objects("value") and get_value/set_value/etc calls in ElementBackendObject?  I guess in theory some of those calls won't be used for multi-valued things.  The best solution is probably to have them instead search for things of type CfgBuiltin::VALUE, but that gives the possibility of multiple hits.  Should we just return the first for get_value/set_value/etc w/ a warning on stderr, or do you have a different suggestion?

Justin

On Tue, 22 Apr 2003 12:37:27 -0400
Justin Yackoski <ju...@sk...> wrote:

> An initial apache parser has been checked in that works with either
> apache or apaceh2, though it is named App:Apache;:Apache2 as I intend
> to make it compatible with Apache 2.0, and then backport it if
> necessary to support 1.3.  I don't think much, if anything, will need
> to change though.
> 
> Right now, LoadModule is the only directive really supported in the
> type definition, and its value tags are "module" and "path".  The rest
> still use "value" for all their parameters.  Also, I changed the type
> definitions and all parser-related stuff to judge whether a node is a
> value based on its type and not on its tag.  I will try to do the same
> for the library and the GUIs.  
> 
> Justin
> 
> -- 
> SkiingYAC
> Custom Solutions
> http://www.SkiingYAC.com
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Config4gnu-developer mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/config4gnu-developer
> 
> 


-- 
SkiingYAC
Custom Solutions
http://www.SkiingYAC.com

[Config4gnu-developer] initial Apache parser checked in

[Justin Y. <ju...@sk...>]

An initial apache parser has been checked in that works with either apache or apaceh2, though it is named App:Apache;:Apache2 as I intend to make it compatible with Apache 2.0, and then backport it if necessary to support 1.3.  I don't think much, if anything, will need to change though.

Right now, LoadModule is the only directive really supported in the type definition, and its value tags are "module" and "path".  The rest still use "value" for all their parameters.  Also, I changed the type definitions and all parser-related stuff to judge whether a node is a value based on its type and not on its tag.  I will try to do the same for the library and the GUIs.  

Justin

-- 
SkiingYAC
Custom Solutions
http://www.SkiingYAC.com

Re: [Config4gnu-developer] make install, DESTDIR and --prefix=something else failure

[Christian L P. <pe...@co...>]

Hmm... It is dynamic right?  So it depends on how you have your LD environment setup.  I actually added /usr/local/config4gnu/lib to my /etc/ld.so.conf file and ran ldconfig.  At least this is my understanding.  I could be wrong.

[pearcec@insight config4gnu-0.1.8]$ ldd src/wrappers/perl5/.libs/config4gnu.so | grep config
        libconfig4gnu.so.0 => /usr/local/config4gnu/lib/libconfig4gnu.so.0 (0x40368000)

[pearcec@insight config4gnu-0.1.8]$ export LD_LIBRARY_PATH=src/libconfig4gnu/.libs/
[pearcec@insight config4gnu-0.1.8]$ ldd src/wrappers/perl5/.libs/config4gnu.so | grep config
        libconfig4gnu.so.0 => src/libconfig4gnu/.libs/libconfig4gnu.so.0 (0x40368000)

Still reading...
--
Christian Pearce
www.commnav.com


On Thu, 17 Apr 2003 14:59:02 -0400, Justin Yackoski wrote:
> 
> Another problem which may be related is that src/wrappers/.libs/config4gnu.so still doesn't get linked properly.  If /usr/local/lib/libconfig4gnu.so.0 exists, it gets links against that instead of src/libconfig4gnu/.libs/libconfig4gnu.so.0.  If that file does not exist, then the copy in src/... doesn't get found.
> 
> Christian/Jason, if you run
> 
> ldd src/wrapers/.libs/config4gnu.so
> 
> in the source tree, does it find the correct libconfig4gnu.so.0 for you?
> 
> 
> Justin
> 
> -- 
> SkiingYAC
> Custom Solutions
> http://www.SkiingYAC.com
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Config4gnu-developer mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/config4gnu-developer
>

Re: [Config4gnu-developer] make install, DESTDIR and --prefix=something else failure

[Christian L P. <pe...@co...>]

Justin,

I am running the follow versions :

[pearcec@insight pearcec]$ rpm -q libtool automake autoconf
libtool-1.4.3-5
automake-1.6.3-5
autoconf-2.57-3

Let it be know I was building from the tar ball and not cvs.  Due to the fact I couldn't get the SWIG portion of the code to work.

I am not an expert with libtool, but wouldn't it be using the one that you are bundling with?  And if I am using the src tar ball automake and autoconf would have already run?

--
Christian Pearce
www.commnav.com


On Thu, 17 Apr 2003 14:14:31 -0400, Justin Yackoski wrote:
> 
> Christian,
> 
> Ah yes, the libtool problem.  A while back, I had the same problem.  I believe it was caused by a buggy version of libtool/ltmain.sh or possibly automake/autoconf.  Some google searching seems to confirm this.  I'm pretty sure upgrading my libtool (I'm currently using 1.4.1) fixed it, as I just checked and I'm able to use --prefix, although DESTDIR doesn't work.  You might also check that autoconf (I'm using 2.57)  and automake (1.7.2) are also up to date.  I'd hold off on trying upgrading until we hear from Jason though :)
> 
> Jason, do you remember anything more about what we did to fix this?  Also, I noticed that Makefile.in has a line near the top where DESTDIR is conspicuously set to nothing.  My instincts tell me that it should be something like:
> 
> DESTDIR = @DESTDIR@
> 
> but you know more about makefiles than I do.  Any ideas?
> 
> Justin
> 
> On Thu, 17 Apr 2003 12:32:26 EDT
> "Christian L Pearce " <pe...@co...> wrote:
> 
> > I attempted a make install and ran into a couple of problems.
> > 
> > 1.  I like to use the DESTDIR variable that I believe starts with
> > autoconf, but I am not certain.   It allows you to specify a
> > destination directory when running make install.  This make it easy to
> > examine that files are going to be install were.  I use it all the
> > time.  I know rpm make heavy use of it as well. (BTW I will write the
> > rpm spec file)  I am not an expert in how automake and autoconf works.
> >  I only understand it conceptual.  Is this something you guys can fix?
> >   If not I will do some more reading and come up with a fix for you.
> > 
> > 2. Based on the fact I couldn't use DESTDIR, I decided to try
> > --prefix=/usr/local/config4gnu.  I ran into a problem :
> > 
> > make[4]: Entering directory
> > `/home/pearcec/config4gnu-0.1.8/src/wrappers/perl5' make[4]: Nothing
> > to be done for `install-exec-am'./bin/sh ../../../mkinstalldirs
> > /usr/local/config4gnu/lib/config4gnu/perl/bin/sh ../../../libtool 
> > --mode=install /usr/bin/install -c config4gnu.la
> > /usr/local/config4gnu/lib/config4gnu/perl/config4gnu.la libtool:
> > install: error: cannot install `config4gnu.la' to a directory not
> > ending in /usr/local/lib/config4gnu/perl make[4]: ***
> > [install-perlextLTLIBRARIES] Error 1 make[4]: Leaving directory
> > `/home/pearcec/config4gnu-0.1.8/src/wrappers/perl5' make[3]: ***
> > [install-am] Error 2 make[3]: Leaving directory
> > `/home/pearcec/config4gnu-0.1.8/src/wrappers/perl5' make[2]: ***
> > [install-recursive] Error 1 make[2]: Leaving directory
> > `/home/pearcec/config4gnu-0.1.8/src/wrappers' make[1]: ***
> > [install-recursive] Error 1 make[1]: Leaving directory
> > `/home/pearcec/config4gnu-0.1.8/src' make: *** [install-recursive]
> > Error 1
> > 
> > It is complaining about not being about to install in
> > /usr/local/lib/config4gnu/perl.  When I want it to install in
> > /usr/local/config4gnu/lib/config4gnu/perl.  I poked around the
> > /home/pearcec/config4gnu-0.1.8/src/wrappers/perl5/Makefile.am file but
> > wasn't able to figure out a fix.
> > 
> > Still reading the other emails.  And still reading documentation.
> > 
> > --
> > Christian Pearce
> > www.commnav.com
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Config4gnu-developer mailing list
> > Con...@li...
> > https://lists.sourceforge.net/lists/listinfo/config4gnu-developer
> > 
> > 
> 
> 
> -- 
> SkiingYAC
> Custom Solutions
> http://www.SkiingYAC.com
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Config4gnu-developer mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/config4gnu-developer
>

Re: [Config4gnu-developer] make install, DESTDIR and --prefix=something else failure

[Justin Y. <ju...@sk...>]

Another problem which may be related is that src/wrappers/.libs/config4gnu.so still doesn't get linked properly.  If /usr/local/lib/libconfig4gnu.so.0 exists, it gets links against that instead of src/libconfig4gnu/.libs/libconfig4gnu.so.0.  If that file does not exist, then the copy in src/... doesn't get found.

Christian/Jason, if you run

ldd src/wrapers/.libs/config4gnu.so

in the source tree, does it find the correct libconfig4gnu.so.0 for you?


Justin

-- 
SkiingYAC
Custom Solutions
http://www.SkiingYAC.com

Re: [Config4gnu-developer] make install, DESTDIR and --prefix=something else failure

[Justin Y. <ju...@sk...>]

Christian,

Ah yes, the libtool problem.  A while back, I had the same problem.  I believe it was caused by a buggy version of libtool/ltmain.sh or possibly automake/autoconf.  Some google searching seems to confirm this.  I'm pretty sure upgrading my libtool (I'm currently using 1.4.1) fixed it, as I just checked and I'm able to use --prefix, although DESTDIR doesn't work.  You might also check that autoconf (I'm using 2.57)  and automake (1.7.2) are also up to date.  I'd hold off on trying upgrading until we hear from Jason though :)

Jason, do you remember anything more about what we did to fix this?  Also, I noticed that Makefile.in has a line near the top where DESTDIR is conspicuously set to nothing.  My instincts tell me that it should be something like:

DESTDIR = @DESTDIR@

but you know more about makefiles than I do.  Any ideas?

Justin

On Thu, 17 Apr 2003 12:32:26 EDT
"Christian L Pearce " <pe...@co...> wrote:

> I attempted a make install and ran into a couple of problems.
> 
> 1.  I like to use the DESTDIR variable that I believe starts with
> autoconf, but I am not certain.   It allows you to specify a
> destination directory when running make install.  This make it easy to
> examine that files are going to be install were.  I use it all the
> time.  I know rpm make heavy use of it as well. (BTW I will write the
> rpm spec file)  I am not an expert in how automake and autoconf works.
>  I only understand it conceptual.  Is this something you guys can fix?
>   If not I will do some more reading and come up with a fix for you.
> 
> 2. Based on the fact I couldn't use DESTDIR, I decided to try
> --prefix=/usr/local/config4gnu.  I ran into a problem :
> 
> make[4]: Entering directory
> `/home/pearcec/config4gnu-0.1.8/src/wrappers/perl5' make[4]: Nothing
> to be done for `install-exec-am'./bin/sh ../../../mkinstalldirs
> /usr/local/config4gnu/lib/config4gnu/perl/bin/sh ../../../libtool 
> --mode=install /usr/bin/install -c config4gnu.la
> /usr/local/config4gnu/lib/config4gnu/perl/config4gnu.la libtool:
> install: error: cannot install `config4gnu.la' to a directory not
> ending in /usr/local/lib/config4gnu/perl make[4]: ***
> [install-perlextLTLIBRARIES] Error 1 make[4]: Leaving directory
> `/home/pearcec/config4gnu-0.1.8/src/wrappers/perl5' make[3]: ***
> [install-am] Error 2 make[3]: Leaving directory
> `/home/pearcec/config4gnu-0.1.8/src/wrappers/perl5' make[2]: ***
> [install-recursive] Error 1 make[2]: Leaving directory
> `/home/pearcec/config4gnu-0.1.8/src/wrappers' make[1]: ***
> [install-recursive] Error 1 make[1]: Leaving directory
> `/home/pearcec/config4gnu-0.1.8/src' make: *** [install-recursive]
> Error 1
> 
> It is complaining about not being about to install in
> /usr/local/lib/config4gnu/perl.  When I want it to install in
> /usr/local/config4gnu/lib/config4gnu/perl.  I poked around the
> /home/pearcec/config4gnu-0.1.8/src/wrappers/perl5/Makefile.am file but
> wasn't able to figure out a fix.
> 
> Still reading the other emails.  And still reading documentation.
> 
> --
> Christian Pearce
> www.commnav.com
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Config4gnu-developer mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/config4gnu-developer
> 
> 


-- 
SkiingYAC
Custom Solutions
http://www.SkiingYAC.com

[Config4gnu-developer] make install, DESTDIR and --prefix=something else failure

[Christian L P. <pe...@co...>]

I attempted a make install and ran into a couple of problems.

1.  I like to use the DESTDIR variable that I believe starts with autoconf, but I am not certain.   It allows you to specify a destination directory when running make install.  This make it easy to examine that files are going to be install were.  I use it all the time.  I know rpm make heavy use of it as well. (BTW I will write the rpm spec file)  I am not an expert in how automake and autoconf works.  I only understand it conceptual.  Is this something you guys can fix?  If not I will do some more reading and come up with a fix for you.

2. Based on the fact I couldn't use DESTDIR, I decided to try --prefix=/usr/local/config4gnu.  I ran into a problem :

make[4]: Entering directory `/home/pearcec/config4gnu-0.1.8/src/wrappers/perl5'
make[4]: Nothing to be done for `install-exec-am'.
/bin/sh ../../../mkinstalldirs /usr/local/config4gnu/lib/config4gnu/perl
/bin/sh ../../../libtool  --mode=install /usr/bin/install -c config4gnu.la /usr/local/config4gnu/lib/config4gnu/perl/config4gnu.la
libtool: install: error: cannot install `config4gnu.la' to a directory not ending in /usr/local/lib/config4gnu/perl
make[4]: *** [install-perlextLTLIBRARIES] Error 1
make[4]: Leaving directory `/home/pearcec/config4gnu-0.1.8/src/wrappers/perl5'
make[3]: *** [install-am] Error 2
make[3]: Leaving directory `/home/pearcec/config4gnu-0.1.8/src/wrappers/perl5'
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory `/home/pearcec/config4gnu-0.1.8/src/wrappers'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/home/pearcec/config4gnu-0.1.8/src'
make: *** [install-recursive] Error 1

It is complaining about not being about to install in /usr/local/lib/config4gnu/perl.  When I want it to install in /usr/local/config4gnu/lib/config4gnu/perl.  I poked around the /home/pearcec/config4gnu-0.1.8/src/wrappers/perl5/Makefile.am file but wasn't able to figure out a fix.

Still reading the other emails.  And still reading documentation.

--
Christian Pearce
www.commnav.com

Re: [Config4gnu-developer] Community Maintaining there own modules...

[Justin Y. <ju...@sk...>]

I can't speak for Jason, but here's what I'd had envisioned:

An install (say via RPM since you sem to like those :) puts, i.e., ssh-server-config.xml in the config4gnu "classes" directory, and puts App/SSH/Server.pm in the CFGXML/Parser directory.  It then tells config4gnu to configure itself to add/modify in config4gnu.xml the relevant sections, adding something like the XML I put in my last email.

What I'd also *really* like to see is a central repository *in addition* to the above steps during the package install.  This would be on our website, and a user could use a CFG UI and say "I want to configure FOO", and they'd enter the name of the application/server, path to the config file, and maybe the version, and they'd get a list of matches.  They'd pick one, and CFG would download the 2 files needed and add it to config4gnu.xml.  

This would let people more easily share these files.  Perhaps when someone went to manually add a new configuration object using files already on their hard drive, CFG would prompt them to check whether our central repository already has the files.  In theory, they'd only be prompted if they're adding files unknown to the repository, since they're either adding them manually because they made them themselves, or they got them from some other website because they couldn't find them in the repository.  We'd then review submissions and add them as needed.

This is down the road though.

Justin

On Thu, 17 Apr 2003 10:32:58 EDT
"Christian L Pearce " <pe...@co...> wrote:

> How do you guys envision the process of applications developers
> maintaining there own modules?
> 
> Would the perl modules and XML configuration spec files get maintained
> in the config4gnu project?  Or do they have the modules in their own
> source code?  So when the app gets installed it registers perl modules
> and XML configuration spec files in some shared directory on the the
> users system.
> 
> --
> Christian Pearce
> www.commnav.com
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Config4gnu-developer mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/config4gnu-developer
> 
> 


-- 
SkiingYAC
Custom Solutions
http://www.SkiingYAC.com

Re: [Config4gnu-developer] config4gnu.php and php setup?

[Justin Y. <ju...@sk...>]

On Thu, 17 Apr 2003 10:10:25 EDT
"Christian L Pearce " <pe...@co...> wrote:


> Two things.  I am going to attempt extend the Common::Flatfile perl
> module to create a App::SSH perl module to handle SSH configurations
> files.  Having said that I have the following questions.  Mind you I
> still haven't read all the documentation.  (NOTE: I dropped the
> CFGXML::Parser from the perl module Namespace.  I am attempting to
> follow the documentation conventions.)

I would actually suggest against extending the flatfile parser, as it probably will not fit your needs.  If you're intending to work with /etc/ssh/sshd_config, that file has a format more like:

Directive Value
Directive Value
Directive Value

whereas the flatfile parser is just for a file that is:

Value
Value
Value

The main question I have is whether /etc/ssh/sshd_config has different sections or if its hierarchy is "flat".  I believe it is flat.  /etc/ssh/ssh_config, however, seems to define sections using a slightly different syntax than apache (though I think you're working with /etc/ssh/sshd_config).  The next question is whether directives can have multiple values, which it appears that at least the "Subsystem" directive can.

It actually appears very similar to an Apache format file, except that is has no sections.  If you try to parse it using Common::Apache, I think you'll find you get a pretty good (albeit generic)  XML representation.

> 1. How does the system register files to be configured?  When I loaded
> the php extention in my browser there are not files to be configured.

There is a "main config file" called config4gnu.xml that by default gets put in ${prefix}/etc/, (usually /usr/local/etc).  If its not there, that's likely your problem.

> 2. How do you handle multiple configuration files for the same
> package.  For instance the ssh config files sshd_config and
> ssh_config. 

Well, the config4gnu.xml file defines each configuration "object" so you could have a "SSH" node and then under it a "Client" and a "Server" node for each of those 2 files.  So I guess you do want to edit ssh_config as well...  We'll probably need to generalize the Common::Apache parser a little to handle how ssh_config defines "Host" sections...

Sample XML to put in config4gnu.xml:

  <section>
    <name>SSH</name>
    <application>
      <name>SSH Server</name>
      <parser-module>CFGXML::Parser::Common::Apache</parser-module>
      <configfile>/etc/ssh/sshd_config</configfile>
    </application>
    <application>
      <name>SSH Client</name>
      <parser-module>CFGXML::Parser::Common::Apache</parser-module>
      <configfile>/etc/ssh/ssh_config</configfile>
    </application>
  </section>

Once you've extended Common::Apache, you'll of course want to put App::SSH instead, or actually you may want App:SSH::Server and App:SSH::Client depending on if the server & client config are different enough that 2 parsers are necessary (which I suspect is the case).  Also note that for ssh_config, Common::Apache will currently not recognize "Host" as indicating a section, so everything will probably be flat, or it may not work at all if you've got something really weird in it, I don't know what all you can do in ssh_config to be honest.

3. Do you have any recommendations for taking on ssh?  I
> think it will be easier that samba and apache.

Start with sshd_config, and extend Common::Apache, but read through this email first since you don't want to extend Common::Apache right away.  The only things you'll need to put in the extended parser when you do make it are a some lines in an init() function to set some options.  The rest should be done for you by Common::Apache.  Here's a perl script you can put in test/parsers to let you easily test what the XML output of sshd_config will be:

#!/usr/bin/perl -I ../../src/parsers -I ../../src/wrappers/perl5 -I ../../src/wrappers/perl5/.libs
use CFGXML::Parser::Common::Apache;

$parser = new CFGXML::Parser::Common::Apache;
$parser->run("load");


Just copy sshd_config into /tmp and chmod +r it, then as a normal user run the above script with /tmp/sshd_config as the only argument  To look at the XML you may also want to pipe stdout thru "xmllint --format" if you have xmllint handy.  Make sure you pipe stderr to /dev/null if you do that since you'll get some errors the first time around about properties not being supported.

Now, you'll be able to read the XML you get in any of the UIs, but the XML tags are all generic.  To fix this, run that script again and pipe stderr to a temporary file.  This file will contain a list of properties that libconfig4gnu tried to add to the XML but which it didn't know about so it defaulted to generic tags like "property".  

You now need to create an extended parser, say App::SSH::Server and set its ROOTTAG to say 'ssh-server-config'.  You'll also need to copy $prefix/share/config4gnu/classes/apache-style.xml to $prefix/share/config4gnu/classes/ssh-server-config.xml.   Run the script again & it should give the exact same output & warnings, except now the root tag of the XML output is 'ssh-server-config'.  

Here is where the fun comes in.  You'll need to edit ssh-server-config.xml to add all of the properties you get errors about.  There may be some cases where you want to use a different XML tag than what the Common::Apache parser wants to use, such as if a directive has a really weird or obscure name, has synonyms/antonyms, etc.  See http://config4gnu.sf.net/docs/extending/backend-parser.html#backend-parser-options for details on this, especially any options with the word RULE in it.

That should keep you busy for a while. :)

Justin

-- 
SkiingYAC
Custom Solutions
http://www.SkiingYAC.com

[Config4gnu-developer] Community Maintaining there own modules...

[Christian L P. <pe...@co...>]

How do you guys envision the process of applications developers maintaining there own modules?

Would the perl modules and XML configuration spec files get maintained in the config4gnu project?  Or do they have the modules in their own source code?  So when the app gets installed it registers perl modules and XML configuration spec files in some shared directory on the the users system.

--
Christian Pearce
www.commnav.com

Re: [Config4gnu-developer] config4gnu.php and php setup?

[Christian L P. <pe...@co...>]

I was looking at file a couple of days ago.  I thought it disappeared.  I remembered the whole dl load function was needed, but I couldn't find it.  Thanks.  

Two things.  I am going to attempt extend the Common::Flatfile perl module to create a App::SSH perl module to handle SSH configurations files.  Having said that I have the following questions.  Mind you I still haven't read all the documentation.  (NOTE: I dropped the CFGXML::Parser from the perl module Namespace.  I am attempting to follow the documentation conventions.)

1. How does the system register files to be configured?  When I loaded the php extention in my browser there are not files to be configured.
2. How do you handle multiple configuration files for the same package.  For instance the ssh config files sshd_config and ssh_config.
3. Do you have any recommendations for taking on ssh?  I think it will be easier that samba and apache.

Feel free to answer with a links.  I am going to go read now.

--
Christian Pearce
www.commnav.com


On Wed, 16 Apr 2003 17:18:21 -0400, Jason Long wrote:
> 
> The config4gnu.php is found in src/wrappers/php and contains only a few
> lines of PHP code to load the PHP extension that makes the Config4GNU
> objects available.
> 
> You should not need to modify it at all. Although it is a generated file
> (and thus not in the CVS) it is getting included in the tarball. If it isn't
> let us know.
> 
> If you get an error saying it can't load the .so file, check that
> php_config4gnu.so is installed in the PHP extension directory. Your setup
> may have extension_dir = . which means the .so file must be in the same
> directory as your PHP script. You'll have to do this manually (I suggest a
> symbolic link).
> 
> `make install' puts php_config4gnu.so in ${prefix}/lib/config4gnu/php. It
> also tries to create a symbolic link from the PHP extension dir (as reported
> by php-config --extension-dir) to the actual install location.
> 
> Hope this helps a little. Keep the questions coming. :)
> 
> Jason
> 
> 
> >>> pe...@co... 04/16/03 16:50 PM >>>
> What goes in this file?  I don't like to ask this question, but the
> documentation is verbose.  Where can I find info on how to setup the php
> client?  Or should I just continue to read code?
> 
> --
> Christian Pearce
> www.commnav.com
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Config4gnu-developer mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/config4gnu-developer
> 
>

Re: [Config4gnu-developer] config4gnu.php and php setup?

[Jason L. <jl...@me...>]

The config4gnu.php is found in src/wrappers/php and contains only a few
lines of PHP code to load the PHP extension that makes the Config4GNU
objects available.

You should not need to modify it at all. Although it is a generated file
(and thus not in the CVS) it is getting included in the tarball. If it isn't
let us know.

If you get an error saying it can't load the .so file, check that
php_config4gnu.so is installed in the PHP extension directory. Your setup
may have extension_dir = . which means the .so file must be in the same
directory as your PHP script. You'll have to do this manually (I suggest a
symbolic link).

`make install' puts php_config4gnu.so in ${prefix}/lib/config4gnu/php. It
also tries to create a symbolic link from the PHP extension dir (as reported
by php-config --extension-dir) to the actual install location.

Hope this helps a little. Keep the questions coming. :)

Jason


>>> pe...@co... 04/16/03 16:50 PM >>>
What goes in this file?  I don't like to ask this question, but the
documentation is verbose.  Where can I find info on how to setup the php
client?  Or should I just continue to read code?

--
Christian Pearce
www.commnav.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Config4gnu-developer mailing list
Con...@li...
https://lists.sourceforge.net/lists/listinfo/config4gnu-developer

Re: [Config4gnu-developer] config4gnu.php and php setup?

[Jason L. <jl...@me...>]

The config4gnu.php is found in src/wrappers/php and contains only a few
lines of PHP code to load the PHP extension that makes the Config4GNU
objects available.

You should not need to modify it at all. Although it is a generated file
(and thus not in the CVS) it is getting included in the tarball. If it isn't
let us know.

If you get an error saying it can't load the .so file, check that
php_config4gnu.so is installed in the PHP extension directory. Your setup
may have extension_dir = . which means the .so file must be in the same
directory as your PHP script. You'll have to do this manually (I suggest a
symbolic link).

`make install' puts php_config4gnu.so in ${prefix}/lib/config4gnu/php. It
also tries to create a symbolic link from the PHP extension dir (as reported
by php-config --extension-dir) to the actual install location.

Hope this helps a little. Keep the questions coming. :)

Jason


>>> pe...@co... 04/16/03 16:50 PM >>>
What goes in this file?  I don't like to ask this question, but the
documentation is verbose.  Where can I find info on how to setup the php
client?  Or should I just continue to read code?

--
Christian Pearce
www.commnav.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Config4gnu-developer mailing list
Con...@li...
https://lists.sourceforge.net/lists/listinfo/config4gnu-developer

[Config4gnu-developer] config4gnu.php and php setup?

[Christian L P. <pe...@co...>]

What goes in this file?  I don't like to ask this question, but the documentation is verbose.  Where can I find info on how to setup the php client?  Or should I just continue to read code?

--
Christian Pearce
www.commnav.com

Re: [Config4gnu-developer] design & access of apache XML format

[Jason L. <jl...@me...>]

I think the generic parser should continue doing what it's doing now, that
is, use multiple <value> tags (maybe <argument> tags would be more
appropriate?). After all, it's not until you treat the file as an Apache
configuration file that the different positions have different meanings.

<directive>
  <name>LoadModule</name>
  <argument>cgi_modules</argument>
  <argument>modules/mod_cgi.so</argument>
</directive>

Of course, there needs to be some way of telling the GUI how to display this
type of property.

Then the Apache-specific parser should be able to assign unique identifiers
for each position of the parameter, e.g.

<LoadModule>
  <modulename>cgi_module</modulename>
  <modulepath>modules/mod_cgi.so</modulepath>
</LoadModule>

Of course, as you say in your email, not having the value tag is going to
prevent the GUI from properly displaying it.

Currently, the GUI looks for <value> tags when deciding what to display. In
the case of the property list, it handles multiple <value> tags by listing
them separated by a space and not allowing you to edit inline. (When you
double-click you get the multi-value form.)

So, based on some of what you were saying, maybe we could make the <value>
tags (or <argument> tags) extend a "value" type, which is what the GUI will
look for when displaying values.

Finally, what you say about XPath is correct. Since Apache will need this,
I'll implement that in resolve_path (and get_path) soon.

Jason


>>> ju...@sk... 04/16/03 10:25 AM >>>
For the apache & similar parsers, I've currently got the following XML:

<apache-style>
  <property>
    <name>Hostname</name>
    <value>myhost.com</value>
  </property>
  <section>
    <name>Directory</name>
    <value>/</value>
    ...
  </section>
  <property>
    <name>LoadModule</name>
    <value>cgi_module</value>
    <value>modules/mod_cgi.so</value>
  </property>
  ...
</apache-style>


The main issue is how to handle multiple value tags.  In most (but not all)
cases, the order of the arguments to the various directives is important, as
each position has a different meaning, such as with LoadModule.  There needs
to be a way to preserve this in the XML.  With the passwd and group files,
we use unique XML tags for each column in the file.  The only other option,
which doesn't seem very good, is to put a position attribute on each value
tag, i.e.:

<property>
  <name>LoadModule</name>
  <value pos="0">cgi_module</value>
  <value pos="1">modules/mod_cgi.so</value>
</property>

The only real advantage of this approach is that everything is still a
"value" tag.

If we use unique XML tags, the problem is that since each directive has a
different number and type of arguments, they won't be consistent as they are
with group and passwd, i.e.:

<property>
  <name>LoadModule</name>
  <modulename>cgi_module</modulename>
  <modulepath>modules/mod_cgi.so</modulepath>
</property>
<property>
  <name>LogFormat</name>
  <logstring quoting="2">%{Referer}i -> %U</logstring>
  <identifier>agent</identifier>
</property>

In this case, we would have some problems:

1) not have a value tag to display in UI
2) can't make a "default" form that works for all directives

To solve this, there are a few solutions I've thought of:

A) make the parameter tags (modulename, modulepath, logstring, identifier,
etc.) extend the type "value" and the UIs look for that instead of a "value"
tag.  This solves problem #1, although the UI has to recognize that there
could be >1 tag of type value.

B) copy some of all of the parameters into a read-only value tag, so the
user can see the current value (although not displayed in a pretty way), but
have to double-click on the form to edit the value, or even better do this
automatically as is currently done with the multi-value control.  This
solves problem #1.

C) give up on default form, make custom form for each multi-valued directive
& use solution B to handle values.  A bad solution to #2

D) a variation on solution A where the first parameter tag extends the type
"value1", the second "value2", etc.  value1, value2, value3, etc. would then
extend value.  This way the UI has something of type "value" to display for
the value if you just want to display the first, or you can use solution B
to combine all of them into a fake read-only value.  This solves #1, and
provided a default form could be made which only shows each of value1 thru
valueN if they exist (otherwise no control would be shown at all for the
missing valueN's).  This is again a slight variation on solution B but is
adds the ability to locate a particular parameter by its position.

E) don't use custom tags for the parameters, just use value1, value2,
value3, etc.  This makes things simpler, but for humans wanting to locate
the "identifier" for a LogFormat directive, it is more difficult because
they need to know its in a value2 tag instead of a "identifier" tag, i.e.:

resolve_path(".apache-style.logformat.identifier")

vs.

resolve_path(".apache-style.logformat.value2")


I think that solution D seems the best for this problem and can't come up
with anything better, what do you think?


An additional thing I thought of (sorry this is getting so long) is that
apache often has multiple directives (such as LoadModule or LogFormat) in a
row.  How will we address them using resolve_path or similar API calls? 
Right now resolve_path just returns the first match it finds right? 

I can't recall off hand, but I think XPath has a syntax for requesting all
LogFormat directives, such as resolve_path(".apache-style.logformat[ALL]"),
or just a particular one, such as
resolve_path(".apache-style.logformat[2]").  I know thats not the right
syntax, but it seems like we'll need something similar for apache.

Justin

-- 
SkiingYAC
Custom Solutions
http://www.SkiingYAC.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Config4gnu-developer mailing list
Con...@li...
https://lists.sourceforge.net/lists/listinfo/config4gnu-developer

Re: [Config4gnu-developer] design & access of apache XML format

[Jason L. <jl...@me...>]

I think the generic parser should continue doing what it's doing now, that
is, use multiple <value> tags (maybe <argument> tags would be more
appropriate?). After all, it's not until you treat the file as an Apache
configuration file that the different positions have different meanings.

<directive>
  <name>LoadModule</name>
  <argument>cgi_modules</argument>
  <argument>modules/mod_cgi.so</argument>
</directive>

Of course, there needs to be some way of telling the GUI how to display this
type of property.

Then the Apache-specific parser should be able to assign unique identifiers
for each position of the parameter, e.g.

<LoadModule>
  <modulename>cgi_module</modulename>
  <modulepath>modules/mod_cgi.so</modulepath>
</LoadModule>

Of course, as you say in your email, not having the value tag is going to
prevent the GUI from properly displaying it.

Currently, the GUI looks for <value> tags when deciding what to display. In
the case of the property list, it handles multiple <value> tags by listing
them separated by a space and not allowing you to edit inline. (When you
double-click you get the multi-value form.)

So, based on some of what you were saying, maybe we could make the <value>
tags (or <argument> tags) extend a "value" type, which is what the GUI will
look for when displaying values.

Finally, what you say about XPath is correct. Since Apache will need this,
I'll implement that in resolve_path (and get_path) soon.

Jason


>>> ju...@sk... 04/16/03 10:25 AM >>>
For the apache & similar parsers, I've currently got the following XML:

<apache-style>
  <property>
    <name>Hostname</name>
    <value>myhost.com</value>
  </property>
  <section>
    <name>Directory</name>
    <value>/</value>
    ...
  </section>
  <property>
    <name>LoadModule</name>
    <value>cgi_module</value>
    <value>modules/mod_cgi.so</value>
  </property>
  ...
</apache-style>


The main issue is how to handle multiple value tags.  In most (but not all)
cases, the order of the arguments to the various directives is important, as
each position has a different meaning, such as with LoadModule.  There needs
to be a way to preserve this in the XML.  With the passwd and group files,
we use unique XML tags for each column in the file.  The only other option,
which doesn't seem very good, is to put a position attribute on each value
tag, i.e.:

<property>
  <name>LoadModule</name>
  <value pos="0">cgi_module</value>
  <value pos="1">modules/mod_cgi.so</value>
</property>

The only real advantage of this approach is that everything is still a
"value" tag.

If we use unique XML tags, the problem is that since each directive has a
different number and type of arguments, they won't be consistent as they are
with group and passwd, i.e.:

<property>
  <name>LoadModule</name>
  <modulename>cgi_module</modulename>
  <modulepath>modules/mod_cgi.so</modulepath>
</property>
<property>
  <name>LogFormat</name>
  <logstring quoting="2">%{Referer}i -> %U</logstring>
  <identifier>agent</identifier>
</property>

In this case, we would have some problems:

1) not have a value tag to display in UI
2) can't make a "default" form that works for all directives

To solve this, there are a few solutions I've thought of:

A) make the parameter tags (modulename, modulepath, logstring, identifier,
etc.) extend the type "value" and the UIs look for that instead of a "value"
tag.  This solves problem #1, although the UI has to recognize that there
could be >1 tag of type value.

B) copy some of all of the parameters into a read-only value tag, so the
user can see the current value (although not displayed in a pretty way), but
have to double-click on the form to edit the value, or even better do this
automatically as is currently done with the multi-value control.  This
solves problem #1.

C) give up on default form, make custom form for each multi-valued directive
& use solution B to handle values.  A bad solution to #2

D) a variation on solution A where the first parameter tag extends the type
"value1", the second "value2", etc.  value1, value2, value3, etc. would then
extend value.  This way the UI has something of type "value" to display for
the value if you just want to display the first, or you can use solution B
to combine all of them into a fake read-only value.  This solves #1, and
provided a default form could be made which only shows each of value1 thru
valueN if they exist (otherwise no control would be shown at all for the
missing valueN's).  This is again a slight variation on solution B but is
adds the ability to locate a particular parameter by its position.

E) don't use custom tags for the parameters, just use value1, value2,
value3, etc.  This makes things simpler, but for humans wanting to locate
the "identifier" for a LogFormat directive, it is more difficult because
they need to know its in a value2 tag instead of a "identifier" tag, i.e.:

resolve_path(".apache-style.logformat.identifier")

vs.

resolve_path(".apache-style.logformat.value2")


I think that solution D seems the best for this problem and can't come up
with anything better, what do you think?


An additional thing I thought of (sorry this is getting so long) is that
apache often has multiple directives (such as LoadModule or LogFormat) in a
row.  How will we address them using resolve_path or similar API calls? 
Right now resolve_path just returns the first match it finds right? 

I can't recall off hand, but I think XPath has a syntax for requesting all
LogFormat directives, such as resolve_path(".apache-style.logformat[ALL]"),
or just a particular one, such as
resolve_path(".apache-style.logformat[2]").  I know thats not the right
syntax, but it seems like we'll need something similar for apache.

Justin

-- 
SkiingYAC
Custom Solutions
http://www.SkiingYAC.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Config4gnu-developer mailing list
Con...@li...
https://lists.sourceforge.net/lists/listinfo/config4gnu-developer