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@xxxxxxxxxx>
> To: "Jeroen Cranendonk" <j.cranendonk@xxxxxxxx>
>
> > 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@xxxxxxxxx
> http://mail.gnome.org/mailman/listinfo/xml
>
|
