RE: [xml] xmlWriter

["Zlatkovic, Igor" <Igor Zlatkovic Dresdner-Bank com>]

Even without looking at the email address :), the number of smileys :))) in
your posts is a strong evidence for the origin from the Netherlands 8-))) I
expect this xmlWriter :) to become a freakin' funny thing :))) :-P

Ciao,
Igor


> 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
>
> _______________________________________________
> xml mailing list, project page  http://xmlsoft.org/
> xml gnome org
> http://mail.gnome.org/mailman/listinfo/xml