The problem is that some nodes are allocated by libxml by parsing documents, processing xsl, etc, and some directly by ruby. I think the hybrid approach is necessary in order to get the speed benefits of using libxml, and I think a hybrid approach to freeing is therefore necessary. It does seem to demand a bit more smarts though, from the memory freeing mechanisms.
Ah - interesting. A hybrid approach is extremely difficult because it means you have to keep track of the ruby to libxml object mapping. For example, say you have some ruby code that create a libxml node. That ruby object would then implement a free method that frees the libxml node. But let's say you end up with a 2nd ruby object pointing to the same libxml object (which is really easy to do) - now you have a problem.
For SWIG I implemented support for mapping between C pointers and Ruby objects by using a Hash Table (ruby's built in one, st_table). That allows you to enforce a one-to-one Ruby to C object mapping. Do we want to do something like that here? The couple issues with it are:
* You have to hook it into every single binding method (easy in SWIG since its all auto-generated)
* Ruby object ids get reused, so you have to clean out old objects from the hash table as soon as they are freed.
If you have such a mapping, then a hybrid approach becomes doable as long as you know absolutely for sure when a Ruby object owns a libxml object and when it doesn't. When it does, you assign a free method. When it doesn't, you don't.
If we go down this approach, it might be worth using SWIG. My only problem with SWIG is that the SWIG mapping language is very complex, and almost no one is going to understand it.
Charlie
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ libxml-devel mailing list libxml-devel@rubyforge.org http://rubyforge.org/mailman/listinfo/libxml-devel
