[xmlsec] xmlsec library, memory allocation and initialization

[Aleksey Sanin]

Hi, Marius!

I have good and bad news for you. The good news is that I am doing
some code refactoring right now and you might get all you want when
I am done. My current plan is to create an object system similar to one
found in GLib/GTK with universal constructors and destructors.
The bad news is that you still need to have something similar in LibXML
as far as I can understand. And I am not sure that this will be easy.

Aleksey



Marius Kjeldahl wrote:

> Hi all (and Aleksey)...
>
> I'm embedding libxml2 and xmlsec into lua (http://www.lua.org/) and 
> plan on using this for various applications dealing with secure credit 
> card transactions.
>
> Lua (and most other scripting languages) uses different memory 
> management than the explicit alloc/free found in lower level 
> languages, and ideally I would like to avoid introducing "c-style" 
> memory management in the scripting part of the application.
>
> In lua, it is possible to add something called "metatables" to objects 
> (in general) and "userdata" (which is memory allocated by the lua 
> memory allocater which can be garbage collected automatically).
>
> If xmlsec would separate memory allocation from initialization, 
> supporting garbage collection (and other methods, like reference 
> counting that perl use) would be quite easy.
>
> In xmlsec the method xmlSecSimpleKeysMngrCreate currently does BOTH 
> memory allocation and initialization. This means it is difficult to 
> allocate the memory from within lua (to enable garbage collection). 
> Ideally, one could split that function into two other functions:
>
> xmlSecSimpleKeysMngrAlloc which allocates the memory
>
> and
>
> xmlSecSimpleKeysMngrInit which initialize it
>
> Then xmlSecSimpleKeysMngrCreate would simply call both of them in 
> order and behave just like before.
>
> These changes throughout the xmlsec library would probably help 
> getting xmlsec into more scriptable cores like Lua, Perl and more, and 
> would ease memory and object management considerably under those 
> higher level languages.
>
> Any other ideas on how to accomplish something similar? I'm writing 
> more and more applications using script languages these days, and I am 
> getting spoiled with avoiding explicit memory management.
>