Re: [xml] xmlWriter

["Jeroen Cranendonk" <j cranendonk emaxx nl>]

From: "Jean Senellart" <senellart systran fr>
To: "Jeroen Cranendonk" <j cranendonk emaxx nl>

> Hi, for you feeling less alone. I have played a bit with your first
version and added few functions (for instance it seemed to me
> that the main application of this sax xmlwriter was to directly write to
file avoiding memory intermediary storage, and that
> gives the xmlNewTextWriterFile function) do some C portability :!), and
add few comments

Cool! :)
I'm not sure what you mean with the memory thing, it's ok for it to use some
memory, as long as it doesn't try to store the whole file in memory in one
go in a domlike structure, and preferably a set amount of memory,
independent of the file size :)
Currently it uses a bit of memory for the element stack, which grows with
the depth of the xml tree, but not with the length/width :)
Could you send me the patches somehow ? :) I've done a bit of tinkering with
the code since the last version I put up,
and am affraid there might be some minor clashes now, but I'm sure I can
merge it ^.^
That's a really good example of why any open source project really needs a
cvs archive too really, it makes patching and
merging so much more easier, and makes it a lot easier to keep people who
add patches up to date with the lastes version :)

> But as far as I can see, most of the work has already be done in tree.c
dump functions (btw, ideally those function should
> themselves eventually use those xmlwriter functions), you have made the
main frame and what need to be done needs of
> course some work, but will be by adapting those functions.

Yep, there's a lot of usable things there, I'm basing it as much as I can on
tree.c and trying to use functions defined elsewhere :)

> what I think is important concerning such a module is not necessarily the
completeness (since nothing was existing before and
>  at the current stage already answers to some needs - completeness can
come with further needs and with the time ) but to
> reach some tested, clean and correct first version
Yep, true :) the first thing I'd like is a version which actually is far
enough to be interesting to be used or at least fiddled with by people,
that'll interest more people to help with it, and supply feedback of actual
users :)

> now for achieving this first stage - on my side, I would vote for patches
or I can help maintaining API/test file (not sure though > what a testsuite
will look like however)

Either are needed, there's still a decent bit of patching needed in the code
I think, and test suits are also a really really really good thing :) for
testsuite's it might be interesting to use some unit test thing if there's
something usable for c++ :) Basicly how I'd have a testsuite would be to
write some code that would write out xml, and have some xml files that
contain an example of exactly how we expect the xml  to come out, and diff
between those two. With all the freeing and mallocing it'd also be good to
defise a way to test against memory leaks, cause I know this code is just
asking for them.
besides that we might want to stick in some form of assertions too, check
the inputs to a function are what we expect them to
be, and check that the outputs to a function are what we expect them to be
:)

Another thing is that there's no real errorhandling in the code yet, like
any old programmer I've focussed first at making the
output work, without thinking and implementing error handling (what if a
file can't be loaded, what if a function is called when we
don't expect it to be, etc. ) I'm not even sure how to report that :) abort
and dump core ? print a message to cerr and return
from the function ? devise a way for each function to return error codes and
let the user of the writer handle it ? :)

Anyways, plenty left to do and ponder :)
     I definatly would like to see those patches you made too ^.^

Greetings and thanks,
    Jeroen Cranendonk