Hi Yoshimi-devs,
just a short notice: I am looking further into this topic, and Will
moreover proposed to go ahead soon with this work to be prepared
for the change and help the Distributions and packagers
So far I've looked through our usages of XML and an adaption seems quite
feasible. The fact that we're already using an XMLWrapper indeed helps to
simplify this task.
Basically, as it stands now, XMLWrapper addresses two concerns:
- providing an API to the outside to navigate and add / retrieve values
- maintaining a context stack and handling nodes to add / convert values
So the second aspect is quite obviously something that could be extracted
into an inner component, which would then encapsulate the library access.
This assessment still leaves some wiggle room regarding details. Notably
there are oddities related to the way how the XMLwrapper::node variable
is carried alongside. More specifically, the endbranch(), which is used
for writing / populating, does a pop() with re-assigning the node, while
the coutnerpart for reading, the exitbranch() only does a pop()
It was this way from the very first version added by Cal to our Git history.
Regarding memory management, the MXML uses ref-counting, but our code seemingly
never interferes with that. We just invoke mxmlDelete(tree) at some points.
So this certainly leads to the question where to place the context stack,
if we retain this feature at all. It could be both privately in the outer
component, or it could be managed by the inner library-facing component.
In any case, we'll have to wrap and create some kind of additional
intermediary data elements, since we obviously do not want the
other code in Yoshimi to touch MXML data types directly any more.
-- Hermann
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
