[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GNUnet-developers] Re: Config file parsing

From: Christian Grothoff
Subject: [GNUnet-developers] Re: Config file parsing
Date: Mon, 1 Jul 2002 05:00:51 -0500

Let's assume for a moment that it would be nice for GNUnet to be
pluggable against OpenSSL or alternatively gnutls. If that is true,
I would think that the same applies to many other projects. Some of
these other projects will face the same issue that they are using
OpenSSL's ANS1 functions to parse a configuration file.

Thus I would suggest to write an API layer that encapsulates both,
the configuration and the encryption functionality of OpenSSL and
that alternatively maps it entirely to OpenSSL or to gnutls and
if needed some configuration parser. 
If gnutls aims to be a drop-in replacement for OpenSSL, this would
of course not be required, in that case, the configuration parser
would just be an addition to gnutls. Either way, this code does 
not make much sense in GNUnet, since it is not really specific to
what we need (features are good, featureitis is bad). If such a
compatibility layer exists, it surely would make sense if GNUnet
would be able to link against it.

Also, it would be advisable to keep the configuration syntax from
OpenSSL. Neither can I see anything wrong with it nor would I like
to have to provide 2 configuration file styles, that would be much
too messy. Again, keeping the configuration syntax the same will
be useful for other applications that currently bind against
OpenSSL -- and where developers would face the same problem.

* I don't mind gnutls. I don't mind
  GNUnet being able to use gnutls, but
* I would mind introducing additional
  dependencies (like libdotconf) or lots
  of compatibility code. That belongs 
  into gnutls or a generic abstraction 
* If I was a gnutls developer,
  I would put it into gnutls and aim for
  100% compatibility. 

Factoring out all GNUnet calls to OpenSSL into a small
module that maps them to OpenSSL/gnutls/
(where the parser accepts the SAME syntax!) would
be ok with me. 

About the LGPL/GPL issue, LGPL is just less restrictive
than the GPL and allows non-free software to link against
it (but not to change the sources and derive closed-source
libraries or applications). The "lesser" GPL was initially
called the "library" GPL and used for libraries such as
GNUnet can use LGPL code without any licensing problems,
but we should preserve the header (license summary) and
note the original source.

Christian (Melbourne, Australia)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]