> > On this we clearly disagree (on the value of the feature, that is).
> > But that's your choice, of course. I'll keep running with it myself
> > until such a time as an alternative exists.
> > Let's, as they say, agree to disagree on it.
>
> FWIW, I do think this would be a nice feature, and would tie
> in nicely with an idea I've been mulling over of having a
> centralised library site for SQL snippets.
>
> However, I did just download wxxml2 to give it a go and
> instantly ran into problems building it on Windows. I'm sure
> I could get over them with a little effort, but a little
> effort for me to build probably means a lot more effort
> helping others in the future :-(
>
> How much work would it be to use libxml2/msxml - assuming you are
> *definitely* going to be working on some XML import/export
> features that we agree would be accepted in principle?
Reasonably easy, considering we're not really using much of the XML
functionality ATM. We don't even need to do a "proper abstraction", we
could just write code that uses libxml directly. (Or perhaps with simple
wrappers around some parts, but not all).
As for the libxml2/msxml - I think going with *just* libxml2 is the way
to go. The APIs are so completely different that it would be two
completely different implementations. And AFAIK, there are no problems
with libxml on Win32 in general.
So yeah, that can definitly be done without an unreasonable amount of
work. If that means that the feature will "live", I'm fine with looking
at that. But I'd like to know that first. (Implementation details aside
of course, there can still be more of those to fix - the feature in
principle, and the general idea of storing the data in a file in the
users homedir etc)
//Magnus