Menu
▾
▴
libxmlplusplus-general
|
From: Stefan S. <se...@sy...> - 2003-02-04 06:23:25
|
hi there, I'v just checked in the latest bits and pieces of today's round of enhancements. Here is a list: * create a 'Document' type * make 'Attribute' a subclass of 'Node' * enhance the tree manipulation API, adding a Node::child_iterator type, as well as new 'insert_child', and 'append_child' methods (in accordance with the usual STL nomenclature) * remove more memory leaks (SaxParser now has its own 'AttributeMap', independent from Node types * new 'Node::find' and 'Node::get_path' methods for use with xpath lookup All this is illustrated in a new example in examples/dom/. The example takes an existing docbook 'article' and modifies it, and does a simple (xpath based) validation test. Here are some further enhancements I'd like to work on: * add a 'Visitor' class to get rid of all the dynamic_casts in the existing examples * clean up the tree access/modification API. In particular: - get rid of all methods involving NodeLists. Use iterators instead. - get rid of [add,get] *_content (iterators, again...) - define what 'get_content' should do if this isn't a text (etc.) node. * decide who can create Nodes, who owns them if they are taken out of a document, etc. May be a 'Store' object may help... What is the reason for the libxml++ code to be split over a set of subdirs ? Is that really necessary ? Now that 'Attribute' is a node, it is also inconsistent. I would suggest to put all libxml++/nodes/ source files into a single place with the rest. Oh, and can we take out the call to './configure' from the autogen.sh script ? I'd like to be able to configure (and build) in a separate build tree, which currently isn't possible. Any comments concerning the new code (please look into the examples/dom/ demo !) are highly appreciated... Regards, Stefan |
|
From: <mu...@t-...> - 2003-02-04 08:39:19
|
On Tue, 2003-02-04 at 08:21, Stefan Seefeld wrote: > hi there, > > I'v just checked in the latest bits and pieces of today's round > of enhancements. Here is a list: I haven't looked at this yet, but didn't I say that you shouldn't take cvs access as permission to just check in whatever you like? The need to revise your patch 6 times should have shown you that you probably need to go a bit slower. Your arrogance is beginning to astound me. > * create a 'Document' type > * make 'Attribute' a subclass of 'Node' > * enhance the tree manipulation API, adding a Node::child_iterator > type, as well as new 'insert_child', and 'append_child' methods > (in accordance with the usual STL nomenclature) > * remove more memory leaks (SaxParser now has its own 'AttributeMap', > independent from Node types > * new 'Node::find' and 'Node::get_path' methods for use with xpath lookup Who gave you permission to make these major API changes? As far as I know we have not branched yet. Now we will have to do a lot of work to branch and revert these changes in the 1.0 branch. > All this is illustrated in a new example in examples/dom/. The example takes > an existing docbook 'article' and modifies it, and does a simple (xpath > based) validation test. > > Here are some further enhancements I'd like to work on: > > * add a 'Visitor' class to get rid of all the dynamic_casts in the existing > examples Let's patches for all the other stuff please, and let's apply them until we've branched. > * clean up the tree access/modification API. In particular: > - get rid of all methods involving NodeLists. Use iterators instead. > - get rid of [add,get] *_content (iterators, again...) > - define what 'get_content' should do if this isn't a text (etc.) node. > * decide who can create Nodes, who owns them if they are taken out of a document, > etc. May be a 'Store' object may help... > > What is the reason for the libxml++ code to be split over a set of subdirs ? > Is that really necessary ? Yes. It's organisation. > Now that 'Attribute' is a node, it is also inconsistent. > I would suggest to put all libxml++/nodes/ source files into a single place with the > rest. > > Oh, and can we take out the call to './configure' from the autogen.sh script ? No, I'd rather that we didn't. > I'd like to be able to configure (and build) in a separate build tree, which > currently isn't possible. Feel free to make your own autogen.sh locally. > > Any comments concerning the new code (please look into the examples/dom/ demo !) > are highly appreciated... > > Regards, > Stefan > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Libxmlplusplus-general mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libxmlplusplus-general -- Murray Cumming mu...@us... www.murrayc.com |
|
From: Stefan S. <se...@sy...> - 2003-02-04 14:47:18
|
Murray Cumming wrote: > On Tue, 2003-02-04 at 08:21, Stefan Seefeld wrote: > >>hi there, >> >>I'v just checked in the latest bits and pieces of today's round >>of enhancements. Here is a list: > > > I haven't looked at this yet, but didn't I say that you shouldn't take > cvs access as permission to just check in whatever you like? The need to > revise your patch 6 times should have shown you that you probably need > to go a bit slower. Your arrogance is beginning to astound me. my WHAT ? Now you calm down a bit, will you ? I'v sent various mails to the list discussing my different proposed additions, and got some positive feedback. Are you able to browse the archives ? I didn't do *any* backward incompatible changes, beside redefining the AttributeMap used by the SaxParser. Further, I fixed quite a number of issues with the old API, and quite massively enhanced its capabilities (simply by allowing more calls to be directly mapped to libxml2). So, in the light of all this, who are you that you call me arrogant ? >>* create a 'Document' type >>* make 'Attribute' a subclass of 'Node' >>* enhance the tree manipulation API, adding a Node::child_iterator >> type, as well as new 'insert_child', and 'append_child' methods >> (in accordance with the usual STL nomenclature) >>* remove more memory leaks (SaxParser now has its own 'AttributeMap', >> independent from Node types >>* new 'Node::find' and 'Node::get_path' methods for use with xpath lookup > > > Who gave you permission to make these major API changes? As far as I > know we have not branched yet. Now we will have to do a lot of work to > branch and revert these changes in the 1.0 branch. What's wrong with these changes going into 1.0 ? What issues do they generate ? There isn't anything (not in cvs, nor in the mailing list) hinting at what kind of changes are acceptable before a branch and what not. My interpretation of the recent discussions here on the list were that the enhancements / clarifications in the API are well worth to go into 1.0. And really, what I did yesterday is just a continuation /wrap-up of the patch that youself checked in. Again, I agree that developers working on a common project ought to stick to a common vision. I think I did my best to do that, and I'd like to continue to do that and contribute to enhance libxml++. It's *your* attitude that I find quite a bit upsetting. It's your commanding tone that's turning me off quite a lot. Who are you that you give me permission or not to do things ? It's not as if I want to subvert the project. Again, if there were any clear guidelines telling me that libxml++ is currently in a feature freeze or something, I obviously would have been more careful. Could you please at least have a look at the changes before calling me words ? Did you actually look at the new demo ? >>What is the reason for the libxml++ code to be split over a set of subdirs ? >>Is that really necessary ? > > > Yes. It's organisation. Can you elaborate a bit ? >> Now that 'Attribute' is a node, it is also inconsistent. >>I would suggest to put all libxml++/nodes/ source files into a single place with the >>rest. >> >>Oh, and can we take out the call to './configure' from the autogen.sh script ? > > > No, I'd rather that we didn't. *That* is what I call arrogant. I'm trying to enhance libxml++, and you don't even take the time explaining why you think the current situation is better than my proposed changes. You do everything to drive away contributors, at least me. I'm seriously considering to just roll my own. It isn't that hard, I just hoped we could reduce the redundancy and work together instead. Your immature attitude makes that very hard. What have the others here on the list to say on these issues ? Does anybody else worry about the project's stability due to my checkins ? Stefan |
|
From: Christophe de V. <cde...@al...> - 2003-02-04 15:49:38
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi folks, It seems we have a small problem :-/ As the official maintener of libxml++, I must say a few words. My goal here is to clarify the situation, and to avoid the project to A few weeks ago we decided with Murray that current API would be the 1.0 one, and that no changes would be done on it, except for bugfix or adding validation. Then Stefan came with really good ideas to make libxml++ a better wrapper of libxml++. More than that, it would permit to implement easily some features like xpath. I'm reminding this to you since, in my opinion, it permit to andersand why Murray did not appreciate that accessors has been *added*, and so the API changed (the initial patch of Stefan almost did not change the API, just reimplemented it differently). Now I must admit that the tone he used would have irritate almost anybody. I won't give reason to one or another of the protagonists, I just don't want the good work of both of you not to be loosed for libxml++. You both have more experience than me and you cannot image how I appreciate your participation on the project. Stefan, the last modifications you added are definitly good ones, but to preserve everybody's nerves, we'll keep them (iterator stuffs) on the unstable branch, and the future 1.0 version will keep the current API. As Murray always did on this project, I invite you to warn us if you're going to commit some changes (backward compatible or not) in the API, so such situations won't (I hope) happen again. Some discussions we had about evolution of the lib were implicitly concerning the future unstable branch. I could have been more explicit about it, sorry. Now I let you both "laver votre linge sale entre vous" ;-) Best regards, Christophe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj4/4PMACgkQB+sU3TyOQjBBSACeOuR+19qW2kR3XjcoPj5br7Qy LicAoI7Wk9tLLM/jP1PNY/7Wb22oxqXQ =aQ4h -----END PGP SIGNATURE----- |
|
From: Stefan S. <se...@sy...> - 2003-02-04 16:17:42
|
Hi Christophe, Christophe de VIENNE wrote: > I won't give reason to one or another of the protagonists, I just don't want > the good work of both of you not to be loosed for libxml++. You both have > more experience than me and you cannot image how I appreciate your > participation on the project. thanks for the encouraging words. Yes indeed, I'd *much* appreciate to keep our *common* efford going. While working together can be hard at times, I definitely think it is worth the efford. > Stefan, the last modifications you added are definitly good ones, but to > preserve everybody's nerves, we'll keep them (iterator stuffs) on the > unstable branch, and the future 1.0 version will keep the current API. ok, I'm fine with that. But please lets have a close look at the old API and clearly identify the problems with it. There are quite a number of places where the code will either leak or at least not be clear enough to developers as to what happens, and what the user/developer is expected to do (my old song of ownership semantics...) In fact, I think we should go over the changes (I *did* try hard to keep each individual commit in focus on a precise and atomic goal) and evaluate whether they present a fix that's worth preserving for the 1.0 stable branch or not. For example the redefinition of AttributeMap is - while a major API change - clearly a fix of a memory leak. > As Murray always did on this project, I invite you to warn us if you're going > to commit some changes (backward compatible or not) in the API, so such > situations won't (I hope) happen again. ok. Again, I did discuss all of my changes on the list. May be I should have waited longer for feedback, but there were either no or only positive comments to the issues I addressed, so I didn't anticipate any opposition. > Some discussions we had about evolution of the lib were implicitly concerning > the future unstable branch. I could have been more explicit about it, sorry. > > Now I let you both "laver votre linge sale entre vous" ;-) d'accord (hors de la liste de courriels si possible). Kind regards, Stefan |
|
From: <mu...@t-...> - 2003-02-06 13:11:56
|
On Tue, 2003-02-04 at 15:49, Stefan Seefeld wrote: > Murray Cumming wrote: > > I haven't looked at this yet, but didn't I say that you shouldn't take > > cvs access as permission to just check in whatever you like? The need to > > revise your patch 6 times should have shown you that you probably need > > to go a bit slower. Your arrogance is beginning to astound me. > > my WHAT ? Now you calm down a bit, will you ? > > I'v sent various mails to the list discussing my different proposed > additions, and got some positive feedback. Are you able to browse the > archives ? Everything seems to be sorted out now. I'll just respond quickly again to this. The issue is not whether the changes are appropriate - The point is that you are not a maintainer so you should not make changes without getting permission first - certainly not API changes. I asked Christophe not to give you cvs write access immediately so that you would have the chance to develop the correct habits first. In my experience that is a smoother process. > Who are you that you give me permission or not to do things ? I am the person who revived the project, and created the stable/unstable release plans. I am the person who has successfully released and maintained stable APIs for gtkmm, gnomemm and libsigc++ among others, sucessfully encouraging and integrating many developers. I know how to do this stuff. I am not an official maintainer of libxml++ because I am trying to avoid extra responsibilities, but Christophe has OKed all of my plans. Again, everything seems to be sorted out now. -- Murray Cumming mu...@us... www.murrayc.com |
|
From: Stefan S. <se...@sy...> - 2003-02-06 14:09:01
|
Murray Cumming wrote: > On Tue, 2003-02-04 at 15:49, Stefan Seefeld wrote: > >>Murray Cumming wrote: >> >>>I haven't looked at this yet, but didn't I say that you shouldn't take >>>cvs access as permission to just check in whatever you like? The need to >>>revise your patch 6 times should have shown you that you probably need >>>to go a bit slower. Your arrogance is beginning to astound me. >> >>my WHAT ? Now you calm down a bit, will you ? >> >>I'v sent various mails to the list discussing my different proposed >>additions, and got some positive feedback. Are you able to browse the >>archives ? > > > Everything seems to be sorted out now. I'll just respond quickly again > to this. The issue is not whether the changes are appropriate - The > point is that you are not a maintainer so you should not make changes > without getting permission first - certainly not API changes. Ok, now that is something to discuss. As I repeatedly stated here, I fully agree that having write permission comes with a lot of responsability, for example not to apply 'random changes' as you call it. I never did. Every single change I did was proposed days ahead on the list. Nobody objected. In the contrary, most suggestions were supported. In particular, Christophe (the maintainer) never told me to do this or that, and there is nothing defining what rights I have and what not. I really don't understand where you get the idea that I have to get explicit permission for each checkin. That's not my understanding on what cvs write permissions are for. Had I known, I may not have taken the trouble to join the project, as it is just too cumbersome (instead, I would have rolled my own little project and sent regular mails informing you about stuff I think may interest you so you could create patches and apply them yourself). But again, I think the fun is really to work this out and get an agreement on how libxml++ should look like in its final form. > I asked > Christophe not to give you cvs write access immediately so that you > would have the chance to develop the correct habits first. In my > experience that is a smoother process. From my perspective the problem here is that you have a very strange definition of 'correct habits'. You are certainly not getting me to ask you for checkin permission each time I want to make an checkin. I *never* would make API changes without asking for agreement. So far, the only API changes I made are additions, and I asked whether people would agree on them. Since nobody objected (in what I considered a reasonable time frame), I took it a checkin to that effect would be fine. >>Who are you that you give me permission or not to do things ? > > > I am the person who revived the project, and created the stable/unstable > release plans. Where are those plans ? The only thing about a release I heared was you discussing with Christophe about whether or not to include my first patch into the 1.0 branch (and thus, release). > I am the person who has successfully released and > maintained stable APIs for gtkmm, gnomemm and libsigc++ among others, > sucessfully encouraging and integrating many developers. Now that is quite beside the point. Or do you want me to number all the projects I have been creating/leading/maintaining, too ? That doesn't get us anywhere. We are both developers in the libxml++ project, where we have to show our merrits. In a nutshell, I'd like to see clearly how you (and the other project participants) envision the project's future (where do we want this project to go ?) and the way it is maintained. For me it's really just a matter of efficiency. I'm looking forward to have constructive and open-minded discussions about the project's design and code. But I'm a bit worried about the overhead implied by an overly restrictive development process. Really, the thing may be as simple as stating clearly what kind of changes are acceptable and what are not. Stefan |
|
From: Rolf D. <dub...@pk...> - 2003-02-04 15:52:12
|
> > to go a bit slower. Your arrogance is beginning to astound me. > > my WHAT ? Now you calm down a bit, will you ? Hi guys, could you maybe call down _both_ a little. There a actually people using libxml++. It doesn't really help if the API and the whole project philosophy gets turned upside down everytime a new developer steps up. I know my opinion may be irrelevant, but as a user, I take the freedom to express my whish for a API stable 1.0 release before you start to tear each other apart over major changes of the whole library design? Murray did a lot of work to revive libxml++ development and to get it to an API stable version! But, I also think it might be a good idea to go towards a real libxml-wrapper, rather than a half reimplementation. But kind, gentle, and after 1.0 ? peace brothers ;-) Rolf *************************************************************** Rolf Dubitzky e-mail: Rol...@Ph... s-mail see http://hep.phy.tu-dresden.de/~dubitzky/ *************************************************************** |
|
From: Stefan S. <se...@sy...> - 2003-02-04 16:30:43
|
Hey Rolf, Rolf Dubitzky wrote: > Murray did a lot of work to revive libxml++ development and to get it to an > API stable version! But, I also think it might be a good idea to go towards a > real libxml-wrapper, rather than a half reimplementation. But kind, gentle, > and after 1.0 ? sure. Indeed, I didn't know how many people currently used libxml++, and thus how big an impact my proposed changes would be. I think that the change with the biggest impact is the 'paradigm shift' away from a library implementing itself a dom, towards a thin libxml2 wrapper. In that light, I would really suggest we roll back *all* changes from my side, i.e. branch for a 1.0-release using the version just before my first patch went in. I think that, while quite limitted feature-wise, this is a consistent and self-contained version. My patch and subsequent checkins all work towards a different goal, so their stabilization may make a good target for the next milestone (1.2, say). Doing this would allow the 1.0 branch to stabilize, while not halting future evolution of the developmental branch. And, Murray, be assured, I'll wait with any future checkins for you to be back so we can make sure we have a common vision of where all this is heading. Looking forward to a constructive and open-minded discussion, Stefan |
|
From: Christophe de V. <cde...@al...> - 2003-02-04 17:24:02
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Mardi 4 F=E9vrier 2003 17:32, Stefan Seefeld a =E9crit : > In that light, I would really suggest we roll back *all* changes from my > side, i.e. branch for a 1.0-release using the version just before my > first patch went in. I think that, while quite limitted feature-wise, > this is a consistent and self-contained version. That's ok for me. We'll do branching by the weekend. > Looking forward to a constructive and open-minded discussion, great, me too :) Best regards, Christophe =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj4/9xQACgkQB+sU3TyOQjDtGwCgwsbn0SF1ptVyh/xE1mDItK6f axoAn3EwhKAi7cGQAy2hdEv4JamZu8Re =3Db4JR =2D----END PGP SIGNATURE----- |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X