Configuration file format vs. API (and LDAP)

[co...@dnt.ro]

> How to access the configuration file has not been addressed
> yet so I will put in my $.02. I would like to see an LDAP
> interface to the config file(s) so I can configure multiple
> servers from a central server. Can I get an amen?


Does it mean "use JNDI for the configuration API"? 
I like the idea - even if in the end people will choose another  API 
for Jakarta's config, you can have an implementation on top of JNDI (
allowing LDAP config ).
( BTW, I DOM is much less powerfull than JNDI in some areas - DOM is
designed to represent documentss, while JNDI for federated directories,
it can search, generate change events, etc. )  

I really think LDAP is a great tool for centralized configuration. 
Of course, most people like XML for everything, but keep in mind XML is a
standard for data exchange, not the universal data representation.
Nothing prevent importing/exporting an XML config into LDAP, or an JNDI
provider for the "static XML file" config.

That will also solve the "integration with web servers" problem. It's
almost impossible to avoid configuring the web server ( the connector,
mappings, etc) - and having a common API for configurations ( and using
the "federation" in JNDI ) will provide the best way to do that. 


> As to whether to use XML or properties, why not both? It
> wouldn't take much to preprocess an XML file down to a
> properties file.

Why not both AND native web server config file AND LDAP AND anything else 
makes sense and provides value for enough people ( and someone volunteers
to write a driver for?).

Costin

Re: Configuration file format vs. API (and LDAP)

[James Todd <ja...@eng.sun.com>]

Stefano Mazzocchi wrote:
> 
> 
> BTW, you Sun and IBM people should be more careful about the community
> process.
> 
> There is a proposal by some IBM guy about creating some Configurations
> API that extend the functionality of Properties and friends.
> 

from my perspective, if this is thoughtout a bit we'll be
able to introduce and play with a number of concepts.

regarding extended property stuff ... i've personally been
there and done that. this is not to say that this still
shouldn't be done but i don't feel it should be the keystone
element.

i see more momentum in transposing from a collection of xml
representations of data to/from objects then name/value stuff.
in my mind, xml is just another way to serialize an object ...
in a very human friendly means.

as i see it anyway,

- james

Re: Configuration file format vs. API (and LDAP)

[James Barry <jm...@ibm.net>]

Stefano Mazzocchi wrote:

> 
> BTW, you Sun and IBM people should be more careful about the community
> process.
> 
> >There is a proposal by some IBM guy...<snipped>

As many of the folks on the list know, IBM has been working closely with
Sun and the Java.Apache team to get this project up since last October.
IBM wants Jakarta to succeed, and wants to have its team participate as
part of the community.  Our apologies, if it we haven't so far.

The fortunate part is that we have a lot of developers, and they might
have a good idea or two.  

The downside is that we are a large company and Java and XML are hot, so
a lot of IBM developers want to contribute. (Up to 40,000 or so Java
developers throughout IBM, and growing daily)   We could swamp the list,
which is not our intention.

We will be assembling a team that should be regular contributors and
commenters on this list.  Like we have with Apache HTTP, we will only
have a few speak for the corporation, but they will carry the
contributions of many within IBM.  Until we sort it out, I apologize. 
This Open Source area is new for a lot of our developers.

Be assured that we are excited about the code that will result and will
be basing our products (such as WebSphere Application Server Standard
Edition) on it.  Its our belief that if we use the code, we should
contribute back substantial contributions to the community. ( We
contribute under the Apache license to Apache projects in case you
wonder)  I hope that you find our team will make solid contributions and
follow the community process that you will be putting into place.

We are looking forward to making WebSphere Standard Edition JSP and
Servlet technology available for review and perhaps inclusion into the
Jakarta project.  We are waiting however for Sun to put up its code,
before putting our own code up.  And we will contribute the code as
patches to the combined Jserv/Sun contributed Jakarta codebase, as
opposed to putting up another tree of code.  This is a result of talking
to those involved (Stefano/Jon/Sun etc.), who have worked with us in
defining how we will contribute.  

Though I won't be contribute on this or any other list, I welcome any
comments about IBM, as I do work with the HTTP and Java.Apache core at
helping shape any IBM involvement.  We will listen to your comments
because we want IBM succeed with the Jakarta Community.

I love the way a community with opinions has formed so quickly, and look
forward to seeing the resulting code emerge from Jakarta.


-- 
James Barry
IBM Software Group
Product Manager IBM HTTP Servers & WebSphere
jmbarry@ibm.net
(303) 924-5670
Fax (303) 664-9505
Pager 1-800-759-8888         PIN  # 1461945

Re: Configuration file format vs. API (and LDAP)

[Stefano Mazzocchi <st...@apache.org>]

costin@dnt.ro wrote:
> 
> > How to access the configuration file has not been addressed
> > yet so I will put in my $.02. I would like to see an LDAP
> > interface to the config file(s) so I can configure multiple
> > servers from a central server. Can I get an amen?
> 
> Does it mean "use JNDI for the configuration API"?

BTW, you Sun and IBM people should be more careful about the community
process.

There is a proposal by some IBM guy about creating some Configurations
API that extend the functionality of Properties and friends.

Anybody has any more internal info on this?

-- 
Stefano Mazzocchi       A language that doesn't affect the way you 
                      think about programming, is not worth knowing.
<st...@apache.org>                             Alan J. Perlis
---------------------------------------------------------------------