gcrypt at dstoecker.de
Thu Jan 12 15:05:50 CET 2006
On Thu, 12 Jan 2006, Marcus Brinkmann wrote:
> > I am
> > nevertheless required to have this page released due to the LGPL license
> > of libgcrypt.
> You are required to comply with the conditions of the LGPL. These
> conditions say nothing about a web page.
It is one of the cheapest forms of complying to LGPL/GPL.
> being ignored completely. You say you don't want to spend any amount of
> time to make the patches perfect and separate when getting ignored.
> However, why do you expect that we spend this time to make the patches
> perfect and separate if we don't even know what they would do?
Because I already had multiple time bad experience and don't believe
additional work will help.
I will no longer discuss this part about who is to blame for what as like
always this brings nothing for both sides. Any further discussions
restricted to the helpful parts of technical issues.
> > You have better insight into the topic to
> > find out, how this would be needed to be implemented, as reference
> > counting in the current state with automatic initializer calls is a bit
> > complicated.
> I don't understand what's complicated about it. Can you elaborate?
Reference counting would require exactly one INIT and one FINISH for each
party using the software. As there are "automagically" initialisations in
some calls, it may be complicated to track down different parties (e.g.
libraries, which do no explicit init call). I do not know the internals
well enough to decide how exact reference counting would be. It is always
more complicated to implement such stuff in existing code, where it has
not been designed from the very beginning.
This greatly depends on the real world usage of libgcrypt. Probably a
first step would be an assertion for these cases, so that the programmers
get an information and implement explicit init and shutdown calls. In
the time inbetween the finalize call would not release anything and a
configuration option in autoconf would toogle dummy/real-mode.
Maybe the best would be the introduction of "contexts" into the API/ABI as
additional option and having a global context for legacy applications as
Frediano explained in his mail. Using the deprecated attribute and proper
texts how to fix it in the header file will make updating of legacy
applications much easier. It would not break ABI and API.
In 2-3 years the deprecated stuff and the global context can be removed
(breaking the API) and the problem is solved. Thought before this the
new API must be designed or there will be incompatible changes for
libgcrypt 2 again.
http://www.dstoecker.de/ (PGP key available)
More information about the Gcrypt-devel