From mvette13 at gmail.com Mon Mar 6 07:37:29 2006 From: mvette13 at gmail.com (Mark Van Holstyn) Date: Mon, 6 Mar 2006 07:37:29 -0500 Subject: [libxml-devel] problem deleting nodes and changing attributes Message-ID: We are looking at changing from using rexml in one project to libxml, as it proves to be much faster. However, the ruby libxml binding seems to be missing the capability to remove elements from an XML document (or at least I cannot see how to do so). Also, when trying to set attributes on a node (properties as libxml calls them), the attributes duplicate. If i have a node like so: then in ruby i do (n is the node): n['name'] = 'something else' Now the node looks like: Anyone know what I am missing? Thanks in advance, Mark -- Mark Van Holstyn mvette13 at gmail.com http://lotswholetime.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/libxml-devel/attachments/20060306/2b4782cd/attachment.htm From mvette13 at gmail.com Tue Mar 7 11:01:26 2006 From: mvette13 at gmail.com (Mark Van Holstyn) Date: Tue, 7 Mar 2006 11:01:26 -0500 Subject: [libxml-devel] problem deleting nodes and changing attributes In-Reply-To: References: Message-ID: The duplicating attribute problem has been solved. The version of libxml I had when I was going that was from a Debian repository, rather than the newest gem. That problem does not exist in the newest gem version. -- Mark Van Holstyn mvette13 at gmail.com http://lotswholetime.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/libxml-devel/attachments/20060307/53520547/attachment-0001.htm From rosco at roscopeco.co.uk Wed Mar 8 19:46:50 2006 From: rosco at roscopeco.co.uk (Ross Bamford) Date: Thu, 09 Mar 2006 00:46:50 -0000 Subject: [libxml-devel] libxslt bindings In-Reply-To: <20060228004724.A1911216C10@mailhost.gigave.com> References: <20060227173458.C1DDB216C21@mailhost.gigave.com> <20060228004724.A1911216C10@mailhost.gigave.com> Message-ID: On Tue, 28 Feb 2006 00:47:23 -0000, Sean Chittenden wrote: >> >> So anyway, here's the question: Does anyone know any links >> >> pertaining to building and linking interdependent ruby >> >> extensions? Or have any tips for me? >> > >> > During the dist-bzip2 phase of the makefile, *copy* a version of >> > ruby-libxml's headers into the libxslt tree. Then install a >> > version check at the load of the .so to confirm that ruby's >> > libxml/libxslt bindings are the same as current or within a micro >> > release. >> > >> > How's that sound? -sc >> >> Well, it works, which is good enough for me :) I've now got the >> libxslt-ruby source compiling without warnings and passing all the >> tests. I've not put the version check in yet - is there a better >> way than just comparing them with the header consts at the start of >> Init_libxslt ? > > Nope, that's about it. I'd look for major and minor versions. Daniel > is pretty good about not breaking ABI with micro releases and think > I've done a decent job in the past with the libxml/xsl bindings. -sc > Okay, for now I put in an #error thats hit if RUBY_LIBXML_VERNUM != RUBY_LIBXSLT_VERNUM , so it won't compile if the headers mismatch. Pretty crude I know but I had problems comparing the versions, because right now they're octal consts in the source, but will become decimal at version 1.x. I guess it could just check the string versions instead or something... ? I also added a LIBXML_TEST_VERSION in the Init_libxslt func, I couldn't find an equivalent in libxslt but it shouldn't be difficult to do. I guess libxml-ruby should have the same thing... Apart from that I think this codebase should go into CVS, I've not lost any data for, ooh, days and I'm starting to get jittery having uncommitted stuff ;) -- Ross Bamford - rosco at roscopeco.co.uk From sean at gigave.com Wed Mar 8 19:56:32 2006 From: sean at gigave.com (Sean Chittenden) Date: Wed, 8 Mar 2006 16:56:32 -0800 Subject: [libxml-devel] libxslt bindings In-Reply-To: References: <20060227173458.C1DDB216C21@mailhost.gigave.com> <20060228004724.A1911216C10@mailhost.gigave.com> Message-ID: <20060309005632.GL9496@mailhost.gigave.com> > Okay, for now I put in an #error thats hit if RUBY_LIBXML_VERNUM != > RUBY_LIBXSLT_VERNUM , so it won't compile if the headers > mismatch. Pretty crude I know but I had problems comparing the > versions, because right now they're octal consts in the source, but > will become decimal at version 1.x. I guess it could just check the > string versions instead or something... ? I've used multiple macros in the past and compared them individually... sucks, but auto* makes it a bit nicer. #define MAJOR_VER 0 #define MINOR_VER 3 #define MICRO_VER 5 > I also added a LIBXML_TEST_VERSION in the Init_libxslt func, I > couldn't find an equivalent in libxslt but it shouldn't be difficult > to do. I guess libxml-ruby should have the same thing... > > Apart from that I think this codebase should go into CVS, I've not > lost any data for, ooh, days and I'm starting to get jittery having > uncommitted stuff ;) plz to be committing your code two minutes ago -- Sean Chittenden From rosco at roscopeco.co.uk Wed Mar 8 21:01:38 2006 From: rosco at roscopeco.co.uk (Ross Bamford) Date: Thu, 09 Mar 2006 02:01:38 -0000 Subject: [libxml-devel] libxslt bindings In-Reply-To: <20060309005634.0628D216FCE@mailhost.gigave.com> References: <20060227173458.C1DDB216C21@mailhost.gigave.com> <20060228004724.A1911216C10@mailhost.gigave.com> <20060309005634.0628D216FCE@mailhost.gigave.com> Message-ID: On Thu, 09 Mar 2006 00:56:32 -0000, Sean Chittenden wrote: >> Okay, for now I put in an #error thats hit if RUBY_LIBXML_VERNUM != >> RUBY_LIBXSLT_VERNUM , so it won't compile if the headers >> mismatch. Pretty crude I know but I had problems comparing the >> versions, because right now they're octal consts in the source, but >> will become decimal at version 1.x. I guess it could just check the >> string versions instead or something... ? > > I've used multiple macros in the past and compared them > individually... sucks, but auto* makes it a bit nicer. > > #define MAJOR_VER 0 > #define MINOR_VER 3 > #define MICRO_VER 5 > I considered that, but I'd have liked to be able to do a release against the 0.3.6 libxml release, and adding that to the headers would break that I think. Only a problem for those who compile from CVS, but...? >> I also added a LIBXML_TEST_VERSION in the Init_libxslt func, I >> couldn't find an equivalent in libxslt but it shouldn't be difficult >> to do. I guess libxml-ruby should have the same thing... >> >> Apart from that I think this codebase should go into CVS, I've not >> lost any data for, ooh, days and I'm starting to get jittery having >> uncommitted stuff ;) > > plz to be committing your code two minutes ago > Phew, that's better :) Module is 'libxslt'. It's compiling and testing clean here, you can just run 'rake' to compile and test, hopefully... -- Ross Bamford - rosco at roscopeco.co.uk From sean at gigave.com Wed Mar 8 21:20:41 2006 From: sean at gigave.com (Sean Chittenden) Date: Wed, 8 Mar 2006 18:20:41 -0800 Subject: [libxml-devel] libxslt bindings In-Reply-To: References: <20060227173458.C1DDB216C21@mailhost.gigave.com> <20060228004724.A1911216C10@mailhost.gigave.com> <20060309005634.0628D216FCE@mailhost.gigave.com> Message-ID: <20060309022041.GM5429@mailhost.gigave.com> > >> Okay, for now I put in an #error thats hit if RUBY_LIBXML_VERNUM > >> != RUBY_LIBXSLT_VERNUM , so it won't compile if the headers > >> mismatch. Pretty crude I know but I had problems comparing the > >> versions, because right now they're octal consts in the source, > >> but will become decimal at version 1.x. I guess it could just > >> check the string versions instead or something... ? > > > > I've used multiple macros in the past and compared them > > individually... sucks, but auto* makes it a bit nicer. > > > > #define MAJOR_VER 0 > > #define MINOR_VER 3 > > #define MICRO_VER 5 > > > > I considered that, but I'd have liked to be able to do a release > against the 0.3.6 libxml release, and adding that to the headers > would break that I think. Only a problem for those who compile from > CVS, but...? Naw, that won't break ABI and can be injected at any time. > >> I also added a LIBXML_TEST_VERSION in the Init_libxslt func, I > >> couldn't find an equivalent in libxslt but it shouldn't be > >> difficult to do. I guess libxml-ruby should have the same > >> thing... > >> > >> Apart from that I think this codebase should go into CVS, I've > >> not lost any data for, ooh, days and I'm starting to get jittery > >> having uncommitted stuff ;) > > > > plz to be committing your code two minutes ago > > Phew, that's better :) Module is 'libxslt'. It's compiling and > testing clean here, you can just run 'rake' to compile and test, > hopefully... Will test tonight when I get home. -sc -- Sean Chittenden From rosco at roscopeco.co.uk Thu Mar 9 18:29:11 2006 From: rosco at roscopeco.co.uk (Ross Bamford) Date: Thu, 09 Mar 2006 23:29:11 -0000 Subject: [libxml-devel] libxslt bindings In-Reply-To: <20060309022042.429C3216C10@mailhost.gigave.com> References: <20060227173458.C1DDB216C21@mailhost.gigave.com> <20060228004724.A1911216C10@mailhost.gigave.com> <20060309005634.0628D216FCE@mailhost.gigave.com> <20060309022042.429C3216C10@mailhost.gigave.com> Message-ID: On Thu, 09 Mar 2006 02:20:41 -0000, Sean Chittenden wrote: >> >> Okay, for now I put in an #error thats hit if RUBY_LIBXML_VERNUM >> >> != RUBY_LIBXSLT_VERNUM , so it won't compile if the headers >> >> mismatch. Pretty crude I know but I had problems comparing the >> >> versions, because right now they're octal consts in the source, >> >> but will become decimal at version 1.x. I guess it could just >> >> check the string versions instead or something... ? >> > >> > I've used multiple macros in the past and compared them >> > individually... sucks, but auto* makes it a bit nicer. >> > >> > #define MAJOR_VER 0 >> > #define MINOR_VER 3 >> > #define MICRO_VER 5 >> > >> >> I considered that, but I'd have liked to be able to do a release >> against the 0.3.6 libxml release, and adding that to the headers >> would break that I think. Only a problem for those who compile from >> CVS, but...? > > Naw, that won't break ABI and can be injected at any time. > Okay, I implemented this in both, and updated the version check. It does mean that it won't be possible to compile this libxslt-ruby release with headers from the libxml-ruby 0.3.6 release but since we're bundling the headers it only really affects people who check out just libxslt-ruby from CVS, and try to install the headers themselves... -- Ross Bamford - rosco at roscopeco.co.uk From mvette13 at gmail.com Thu Mar 16 16:36:01 2006 From: mvette13 at gmail.com (Mark Van Holstyn) Date: Thu, 16 Mar 2006 16:36:01 -0500 Subject: [libxml-devel] new libxml-ruby api Message-ID: Recently the libxml-ruby project was picked up, and is being actively developed again. My co-workers and I have been needing an XML solution faster than REXML, and have decided to switch over to libxml. In the process we started adding on some functionality, and would like to continue to help in the development. I would like to use this thread as a forum for open discussion on the likes, dislikes, and desires for the libxml API, specifically I would like to look the XML::Document, XML::Node, XML::Attr, and XML::Note::Set. I am working on writing up a proposed API, and while I work I that I thought I would see what everyone else's idea's are. Please use this thread to list out any features you would like, any naming conventions you want followed, and really anything else you can think of. I will hopefully finish and post my proposed API (influenced by the responses to this thread) sometime this weekend. Thanks for all your help, Mark Van Holstyn -- Mark Van Holstyn mvette13 at gmail.com http://lotswholetime.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/libxml-devel/attachments/20060316/f7109477/attachment.htm From rosco at roscopeco.co.uk Tue Mar 21 17:44:25 2006 From: rosco at roscopeco.co.uk (Ross Bamford) Date: Tue, 21 Mar 2006 22:44:25 -0000 Subject: [libxml-devel] Libxslt doc & release Message-ID: I've just finished adding RDoc and tidying up loose ends on libxslt, and I think it's ready to go out now. The changes are in CVS, I'll pull a release (libxslt-ruby-0.3.6) tomorrow. I don't think I'll be able to upload the docs, though - I still don't seem to have permissions to do that... -- Ross Bamford - rosco at roscopeco.co.uk From mvette13 at gmail.com Wed Mar 22 03:40:40 2006 From: mvette13 at gmail.com (Mark Van Holstyn) Date: Wed, 22 Mar 2006 03:40:40 -0500 Subject: [libxml-devel] API suggestions Message-ID: Here is my suggestions for the API. Let me know what you think. Mark Attatched: OpenOffice.org 2.0 file. If anyone needs a different format let me know. -- Mark Van Holstyn mvette13 at gmail.com http://lotswholetime.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/libxml-devel/attachments/20060322/eb94f870/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: libxml_api.odt Type: application/vnd.oasis.opendocument.text Size: 17762 bytes Desc: not available Url : http://rubyforge.org/pipermail/libxml-devel/attachments/20060322/eb94f870/attachment-0001.bin From sean at gigave.com Wed Mar 22 19:10:59 2006 From: sean at gigave.com (Sean Chittenden) Date: Wed, 22 Mar 2006 16:10:59 -0800 Subject: [libxml-devel] Libxslt doc & release In-Reply-To: References: Message-ID: <20060323001059.GB220@mailhost.gigave.com> > I've just finished adding RDoc and tidying up loose ends on libxslt, > and I think it's ready to go out now. The changes are in CVS, I'll > pull a release (libxslt-ruby-0.3.6) tomorrow. Cool! > I don't think I'll be able to upload the docs, though - I still > don't seem to have permissions to do that... *blinks* You're an admin on rubyforge... not sure how that's possible. Let me know if you're still having problems. -sc -- Sean Chittenden From zdennis at mktec.com Wed Mar 22 22:28:25 2006 From: zdennis at mktec.com (zdennis) Date: Wed, 22 Mar 2006 22:28:25 -0500 Subject: [libxml-devel] API suggestions In-Reply-To: References: Message-ID: <442215D9.2000101@mktec.com> Mark Van Holstyn wrote: > Here is my suggestions for the API. Let me know what you think. > I think Mark's document makes alot of sense. I am using Marks changes currently (patched 0.3.6) and I love the method 'first' that he has added to XML::Node. I fully agree that removing Node::Set in favor or an Array would make the API more powerful. Currently if I want to sort some nodes I have to put them in some other data structure. Ie: array = [] node.find( 'Child1/Child2' ).each { |e| array << e } array.sort{ |a,b| a.meth <=> b.meth } IMO, it is so much nicer to say: node.find( 'Child1/Child2' ).sort{ |a,b| a.meth <=> b.meth } Replaing XML::Attr in place of array, is seems like that should be a hash, no? Maybe this was typo on #5. Mark, are all of these implemented in your patch (i haven't actually looked at the patch contents itself)? If not let me know and I can help fulfill your api changes. On a side note. Since I will be using libxml as well =) I can throw up a Trac site for libxml-ruby if the team would like to use it. Currently we host for rubyeclipse as well (http://rubyeclipse.mktec.com) Zach From mvette13 at gmail.com Thu Mar 23 00:53:06 2006 From: mvette13 at gmail.com (Mark Van Holstyn) Date: Thu, 23 Mar 2006 00:53:06 -0500 Subject: [libxml-devel] API suggestions In-Reply-To: <442215D9.2000101@mktec.com> References: <442215D9.2000101@mktec.com> Message-ID: So far, very few of my proposed changes have made it as far as code. I was waiting for a little feedback before I went ahead and did anything. I will most likely start implementing some of the changed within the next week or so, and will submit anything I do to the libxml-ruby project. Hopefully any/all of these changes look promising. Mark On 3/22/06, zdennis wrote: > > Mark Van Holstyn wrote: > > Here is my suggestions for the API. Let me know what you think. > > > > I think Mark's document makes alot of sense. I am using Marks changes > currently (patched 0.3.6) and > I love the method 'first' that he has added to XML::Node. > > I fully agree that removing Node::Set in favor or an Array would make the > API more powerful. > Currently if I want to sort some nodes I have to put them in some other > data structure. Ie: > > array = [] > node.find( 'Child1/Child2' ).each { |e| array << e } > array.sort{ |a,b| a.meth <=> b.meth } > > IMO, it is so much nicer to say: > > node.find( 'Child1/Child2' ).sort{ |a,b| a.meth <=> b.meth } > > Replaing XML::Attr in place of array, is seems like that should be a hash, > no? Maybe this was typo > on #5. > > Mark, are all of these implemented in your patch (i haven't actually > looked at the patch contents > itself)? If not let me know and I can help fulfill your api changes. > > On a side note. Since I will be using libxml as well =) I can throw up a > Trac site for libxml-ruby > if the team would like to use it. Currently we host for rubyeclipse as > well > (http://rubyeclipse.mktec.com) > > Zach > _______________________________________________ > libxml-devel mailing list > libxml-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/libxml-devel > -- Mark Van Holstyn mvette13 at gmail.com http://lotswholetime.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/libxml-devel/attachments/20060323/b80eef41/attachment.htm From mvette13 at gmail.com Wed Mar 22 22:26:06 2006 From: mvette13 at gmail.com (Mark Van Holstyn) Date: Wed, 22 Mar 2006 22:26:06 -0500 Subject: [libxml-devel] API suggestions In-Reply-To: References: Message-ID: Attatched is the same document in pdf format, as requested... Mark -- Mark Van Holstyn mvette13 at gmail.com http://lotswholetime.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/libxml-devel/attachments/20060322/66c12482/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: libxml_api.pdf Type: application/pdf Size: 102017 bytes Desc: not available Url : http://rubyforge.org/pipermail/libxml-devel/attachments/20060322/66c12482/attachment-0001.pdf From rosco at roscopeco.co.uk Thu Mar 23 03:42:17 2006 From: rosco at roscopeco.co.uk (Ross Bamford) Date: Thu, 23 Mar 2006 08:42:17 -0000 Subject: [libxml-devel] API suggestions In-Reply-To: <442215D9.2000101@mktec.com> References: <442215D9.2000101@mktec.com> Message-ID: On Thu, 23 Mar 2006 03:28:25 -0000, zdennis wrote: > Mark Van Holstyn wrote: >> Here is my suggestions for the API. Let me know what you think. >> > > I think Mark's document makes alot of sense. I am using Marks changes > currently (patched 0.3.6) and > I love the method 'first' that he has added to XML::Node. > > I fully agree that removing Node::Set in favor or an Array would make > the API more powerful. > Currently if I want to sort some nodes I have to put them in some other > data structure. Ie: > > array = [] > node.find( 'Child1/Child2' ).each { |e| array << e } > array.sort{ |a,b| a.meth <=> b.meth } > > IMO, it is so much nicer to say: > > node.find( 'Child1/Child2' ).sort{ |a,b| a.meth <=> b.meth } > I fully agree with this (and many of the other changes Mark proposed), but I disagree that replacing Node::Set etc with an Array is the way to go - bear in mind that libxml-ruby (like libxml) is built for speed and will hopefully stay that way. I tend to favour keeping things much as they are, just using the power of Ruby to build on it. See [1] for some experiments I did to this end a while back. Mostly we can get big benefits by just including Enumerable in a few places, and defining some new convenience methods here and there (obviously from C, the Ruby code I showed just prototypes it. Also, ignore the mention of segfault bugs which have since been cleared). Do note, however, that to_a already works as you'd (probably) expect on node, so you could replace the above with e.g.: node.find('Child1/Child2').to_a.sort { |a,b| ... } or [*node.find('Child1/Child2')].sort { |a,b| ... } > On a side note. Since I will be using libxml as well =) I can throw up a > Trac site for libxml-ruby > if the team would like to use it. Currently we host for rubyeclipse as > well > (http://rubyeclipse.mktec.com) From my point of view, I'm behind with docs as it is and have plenty to do on the code, so it's probably not the right time to do that. Once we get the next round of releases out the way, and things are calmer, it would probably be a great idea :). [1]: http://rubyforge.org/pipermail/libxml-devel/attachments/20051230/778cd254/libxml-x.obj -- Ross Bamford - rosco at roscopeco.co.uk From sean at gigave.com Thu Mar 23 04:17:51 2006 From: sean at gigave.com (Sean Chittenden) Date: Thu, 23 Mar 2006 01:17:51 -0800 Subject: [libxml-devel] API suggestions In-Reply-To: References: <442215D9.2000101@mktec.com> Message-ID: <20060323091751.GC12128@mailhost.gigave.com> > > I fully agree that removing Node::Set in favor or an Array would make > > the API more powerful. > > Currently if I want to sort some nodes I have to put them in some other > > data structure. Ie: > > > > array = [] > > node.find( 'Child1/Child2' ).each { |e| array << e } > > array.sort{ |a,b| a.meth <=> b.meth } > > > > IMO, it is so much nicer to say: > > > > node.find( 'Child1/Child2' ).sort{ |a,b| a.meth <=> b.meth } Nothing says both can't be done... Ross is right, however, in that Node::Set is important and shouldn't be nixed, even though most of the folk out there won't use it once an array interface pops up. Ease of use and REXML compatibility should be a focus, however, and eye'ing their API and shimmying libxml into REXML would be a better use of effort and better way of picking up users/"speeding up ruby." -sc -- Sean Chittenden From zdennis at mktec.com Thu Mar 23 09:48:04 2006 From: zdennis at mktec.com (zdennis) Date: Thu, 23 Mar 2006 09:48:04 -0500 Subject: [libxml-devel] API suggestions In-Reply-To: References: <442215D9.2000101@mktec.com> Message-ID: <4422B524.9020202@mktec.com> Ross Bamford wrote: > > > From my point of view, I'm behind with docs as it is and have plenty to do > on the code, so it's probably not the right time to do that. Once we get > the next round of releases out the way, and things are calmer, it would > probably be a great idea :). > > [1]: > http://rubyforge.org/pipermail/libxml-devel/attachments/20051230/778cd254/libxml-x.obj > I like the file you posted, it shows the beauty of ruby and how easily and cleanly extendable things are. In regards to your comment on XML::Node::Set, the other day I was thinking that it would be nice to know if you had the same object twice. Example doc: 1 2 3 4 5 6 If you are iterating over Container/Item each time you call item_node.parent you will get a new ruby object each time. In total you will get 6 different ruby XML::Node's representing the Containers. In reality you know there are only two Container objects. It may not be desirable to cache ruby XML::Node objects, but perhaps it would be helpful (maybe there is already a way) to accurately compare to parents to see if they actually point to the same node in the xml document? Currently ----------- irb(main):010:0> node.parent.object_id => -606893658 irb(main):011:0> node.parent.object_id => -606901738 irb(main):012:0> node.parent.object_id => -606908328 irb(main):013:0> p1 = node.parent [snip] irb(main):014:0> p2 = node.parent [snip] irb(main):015:0> p1 == p2 => false irb(main):016:0> p1 === p2 => false irb(main):017:0> p1.eql? p2 => false Perhaps add on a libxml_id or xml_id so we can use that and comparing p1 === p2 will return true. Just thinking outloud at this point. Zach From rosco at roscopeco.co.uk Fri Mar 24 11:01:27 2006 From: rosco at roscopeco.co.uk (Ross Bamford) Date: Fri, 24 Mar 2006 16:01:27 -0000 Subject: [libxml-devel] Fwd: [ANN] Libxsl-Ruby 0.3.6 (from ruby-talk) Message-ID: Gems: gem install libxsl-ruby Download: http://rubyforge.org/frs/?group_id=495 Docs: http://libxsl.rubyforge.org/ Brief description: Libxsl-Ruby provides libxslt bindings for Ruby. libxslt is a very fast XSLT engine based on libxml2 (the XML C library developed for the Gnome project). See http://xmlsoft.org/XSLT/ for more information. Libxsl-Ruby builds on (and requires) Libxml-Ruby (http://libxml-rubyforge.org). If not downloading via gems you will need to install libxml-ruby before use. This is part of an ongoing effort to revive the Libxml/Libxsl-Ruby projects with the help of original author Sean Chittenden. -- Ross Bamford - rosco at roscopeco.co.uk From zdennis at mktec.com Mon Mar 27 09:06:09 2006 From: zdennis at mktec.com (zdennis) Date: Mon, 27 Mar 2006 09:06:09 -0500 Subject: [libxml-devel] Making API Suggestions And/Or Patches Message-ID: <4427F151.6000506@mktec.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ross / Sean, Is there a preferred way (for future reference) on how you'd like to receive api suggestions or patches? Inline in email, patches in code, pdfs, openoffice documents, etc.. Thanks, Zach -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEJ/FRMyx0fW1d8G0RAt+BAJ4jBTHkeXH56jyBIwWQ/Ia4lTILtgCeMZYc 8CfzLK1oGDbRONAqaAWvz/A= =EE/s -----END PGP SIGNATURE----- From sean at gigave.com Mon Mar 27 15:05:17 2006 From: sean at gigave.com (Sean Chittenden) Date: Mon, 27 Mar 2006 12:05:17 -0800 Subject: [libxml-devel] Making API Suggestions And/Or Patches In-Reply-To: <4427F151.6000506@mktec.com> References: <4427F151.6000506@mktec.com> Message-ID: <20060327200517.GZ10890@mailhost.gigave.com> > Is there a preferred way (for future reference) on how you'd like to > receive api suggestions or patches? Inline in email, patches in > code, pdfs, openoffice documents, etc.. I can't speak for Ross, but, I'm a fan of plain text emails with bullets or diff -u'ed patches. :) -sc -- Sean Chittenden From rosco at roscopeco.co.uk Mon Mar 27 15:33:56 2006 From: rosco at roscopeco.co.uk (Ross Bamford) Date: Mon, 27 Mar 2006 21:33:56 +0100 Subject: [libxml-devel] Making API Suggestions And/Or Patches In-Reply-To: <20060327200518.74303217008@mailhost.gigave.com> References: <4427F151.6000506@mktec.com> <20060327200518.74303217008@mailhost.gigave.com> Message-ID: On Mon, 27 Mar 2006 21:05:17 +0100, Sean Chittenden wrote: >> Is there a preferred way (for future reference) on how you'd like to >> receive api suggestions or patches? Inline in email, patches in >> code, pdfs, openoffice documents, etc.. > > I can't speak for Ross, but, I'm a fan of plain text emails with > bullets or diff -u'ed patches. :) -sc > Me, too. Generally I prefer patches (for obvious reasons :)) but suggestions / requests etc. are always best as plain-text regardless of content - not just easier to handle right now but it archives better, too. -- Ross Bamford - rosco at roscopeco.co.uk