FW: Autoboxing in php 5.1

php.internals

David Kingma - Jool.nl

21 years ago
Hello Marcus / Adam, While I have nothing against some kind of comment parser in the PHP core, I think it's something which can be done perfectly in the userland (when the ReflectionParameter::getDocComment() is added). Instead I would like to see the XML Canonicalization functionality from libxml2 exposed in userland as a first step to enable XML-signature / XML-Encryption. Or enabling the pre/post handling of the soap request/response as a DOM, before the SOAP extension does his (great) job.(While this is possible with raw post data and outbut buffering, it would be more logical to re-use the same dom object). I'm currently trying to add the Canonicalization functionality, but since I'm not a C expert, it takes a while :) Regards, David

Christian Stocker

21 years ago
On 13.2.2005 19:08 Uhr, David Kingma | jool.nl wrote:
> Hello Marcus / Adam, > > While I have nothing against some kind of comment parser in the PHP core, I > think it's something which can be done perfectly in the userland (when the > ReflectionParameter::getDocComment() is added). > Instead I would like to see the XML Canonicalization functionality from > libxml2 exposed in userland as a first step to enable XML-signature / > XML-Encryption.
It's not either this or that here. There are different people working on different parts of PHP. There is no masterplan, what has to be done first and what later and which resources we use for what. Something is done, when someone has the need for it or feels like doing this. It's not that Adam, Marcus or Greg would now jump on implementing C14N instead of parsing the docblocks .. But I hope, you knew that before ;)
> Or enabling the pre/post handling of the soap > request/response as a DOM, before the SOAP extension does his (great) > job.(While this is possible with raw post data and outbut buffering, it > would be more logical to re-use the same dom object). > > I'm currently trying to add the Canonicalization functionality, but since > I'm not a C expert, it takes a while :)
Shouldn't be to hard, if your talking about the functions described at http://xmlsoft.org/html/libxml-c14n.html chregu
> > Regards, > > David > > >>-----Original Message----- >>From: Marcus Boerger [mailto:helly@php.net] >>Sent: Sunday, February 13, 2005 11:49 AM >>To: Adam Maccabee Trachtenberg >>Cc: johannes@php.net; David Kingma | jool.nl; 'Andi Gutmans'; 'Sean >>Coates'; 'Ante Drnasin'; internals@lists.php.net >>Subject: Re: [PHP-DEV] Autoboxing in php 5.1 >> >>Hello Adam, >> >> ok, you propose a function to prepare the doc comments for further >>processing. While this seems a good idea at first glance it is not >>that easy as you typed it. The problem is that there are different >>tags some of which stop at the next tag, some are just valid for the >>word, some are valid for the current line and some are valid for a >>pragraph. Thus it is better to provide an extension for that. And i >>think it would be a good idea to start this as a set of php scripts. >> >>regards >>marcus >> >>Saturday, February 12, 2005, 7:15:43 PM, you wrote: >> >> >>>On Sat, 12 Feb 2005, Marcus Boerger wrote: >> >>>>ups, reading again i see it, it was >>>>ReflectionProperty::getDocComment() >> >>>There's a generic getDocComment() method, but that just returns the >>>entire blob. You then need to parse the blog using the preg >> >>functions >> >>>to extract individual lines. It would be useful to have the >> >>Reflection >> >>>classes do this. >> >>>Sure, you can do this in userland code: >> >>>$field = 'link'; // specific comment $rc = new >>>ReflectionClass($this); $dc = $rc->getDocComment(); if >>>(preg_match("/@$field +(.+)/", $dc, $matches)) { >>> // do something with $matches; >>>} >> >>>But I think this would be cleaner: >> >>>$field = 'link'; // specific comment $rc = new >>>ReflectionClass($this); $matches = $rc->getDocComment($field); >>>foreach ($matches as >> >>$match) { >> >>> // do something with $match; >>>} >> >>>As I would prefer to put the comment matching logic in the >> >>reflection >> >>>classes, so you can write tools that can rely upon a standardized >>>format for supplying meta data about a class, method, etc. >> >>>Not a big deal one way or another, but this could solve some of the >>>WSDL generation arguments (which I would love to solve) without >>>requiring major language changes, such as native type hinting. >> >>>-adam >>>-- >>>adam@trachtenberg.com | http://www.trachtenberg.com author of >>>o'reilly's "upgrading to php 5" and "php cookbook" >>>avoid the holiday rush, buy your copies today! >> >> >> >> >>-- >>Best regards, >> Marcus mailto:helly@php.net >> >> > >
-- christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | chregu@bitflux.ch | gnupg-keyid 0x5CE1DECB

David Kingma - Jool.nl

21 years ago
Hi Chegru
> -----Original Message----- > > I'm currently trying to add the Canonicalization functionality, but > > since I'm not a C expert, it takes a while :) > > Shouldn't be to hard, if your talking about the functions described at > > http://xmlsoft.org/html/libxml-c14n.html >
That's indeed what I'm talking about. It indeed shouldn't be to hard, but it takes some time get it all up and running on windows :). I managed to get it to work, except for the xmlNodeSet part. How do I get a xmlNodeSet pointer from a dom_nodelist_class_entry? Regards, David

Christian Stocker

21 years ago
On 14.2.2005 23:42 Uhr, David Kingma | jool.nl wrote:
> Hi Chegru > > >>-----Original Message----- >> >>>I'm currently trying to add the Canonicalization functionality, but >>>since I'm not a C expert, it takes a while :) >> >>Shouldn't be to hard, if your talking about the functions described at >> >>http://xmlsoft.org/html/libxml-c14n.html >> > > > That's indeed what I'm talking about. It indeed shouldn't be to hard, but it > takes some time get it all up and running on windows :). I managed to get it > to work, except for the xmlNodeSet part. How do I get a xmlNodeSet pointer > from a dom_nodelist_class_entry?
Maybe you can learn from PHP_FUNCTION(dom_nodelist_item) resp. dom_nodelist_length_read in ext/dom/nodelist.c Or wait until Rob answers ;) I didn't find (in 2 minutes time..) an easy way to do this, Rob did all that stuff. chregu
> > Regards, > > David >
-- christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | chregu@bitflux.ch | gnupg-keyid 0x5CE1DECB

Rob Richards

21 years ago
You have to build an xmlNodeSet by hand. The DOMNodeList class wraps many different types of data to iterate (HastTables, xmlHashTables, nodeIterators, notationIterator, etc...). Everything works on live data so no xmlNodeSets are used since those are static. The iterators all work directly on the real data whever it may live in libxml. Rob Christian Stocker wrote:

David Kingma - Jool.nl

21 years ago
Hi Rob / Chregu, As a first (small) step to implementing xml-security specs (dig-sign, encryption) I created a patch against HEAD to expose (exclusive-)C14n functionality from libxml2. I allows you to canonize a single node (with it's children) or a whole document, with or without comments, exclusive or not. I also created a small test file to show it's functionality. Could you please review the patch or else commit it (if it's ok with everybody)? Thanks David

Pierre-Alain Joye

21 years ago
On Thu, 17 Feb 2005 02:24:02 +0100 D.Kingma@jool.nl (David Kingma | jool.nl) wrote:
> Hi Rob / Chregu, > > As a first (small) step to implementing xml-security specs > (dig-sign, encryption) I created a patch against HEAD to expose > (exclusive-)C14n functionality from libxml2. I allows you to > canonize a single node (with it's children) or a whole document, > with or without comments, exclusive or not. I also created a small > test file to show it's functionality. Could you please review the > patch or else commit it (if it's ok with everybody)?
You have to use text file (.txt) in this list. Or provide a link to the patch. --Pierre

David Kingma - Jool.nl

21 years ago
> -----Original Message----- > D.Kingma wrote: > > > Hi Rob / Chregu, > > > > As a first (small) step to implementing xml-security specs > (dig-sign, > > encryption) I created a patch against HEAD to expose > (exclusive-)C14n > > functionality from libxml2. I allows you to canonize a single node > > (with it's children) or a whole document, with or without comments, > > exclusive or not. I also created a small test file to show it's > > functionality. Could you please review the patch or else > commit it (if > > it's ok with everybody)? > > You have to use text file (.txt) in this list. Or provide a > link to the patch. > > --Pierre
Once again, this time as a txt file. Regards, David

Rob Richards

21 years ago
A few comments from eyeballing the patch: - Depending upon how much c14n functionality there is to be, this might be better off as a standalone extension. This way it wouldn't be dependant upon DOM (especially if PHP is built without it) and allow it to work with simplexml alone. Take xsl for example (although it requires dom to output a dom document, it allows processing via simplexml input - as simplexml has no concept of a document i allow any simplexml element to be used that has a document and just use the document from that node. - Looking at the patch, you may want to change the optional node argument to an array so that multiple nodes can be used for the visibility test - node needs to be initialized to NULL other wise if none is passed it most likely will crash. that being said, if none is passed in you should probably test and use xmlC14NDocSaveTo as it will run much faster as no callback would need to be run. - no need to dupe the xml output buffer content and then dupe it again when creating a zval. would dupe the output buffer straight into the zval. - str_inclusive_ns parameter is st as a string. This however needs to allow to a list of strings since inclusive_ns_prefixes is a xmlChar ** which will be iterated to get all the prefixes. Thats pretty much what jumped out at me as I mentioned I have only looked at the patch and havent played with it. If you are really looking at implementing the xml-security specs, you might want to think about just creating an extension from the xmlsec library. Developng xmlsec is very complicated (just check out the libxml mailing list as this has been brought up before and people are always steered to the xmlsec library). I had started a while back working on an extension for this, but other than some early layout code I haven't found the time to work on it, so before diving in trying to write it from scratch you might want to check out that library. http://www.aleksey.com/xmlsec/ Rob David Kingma | jool.nl wrote:

David Kingma - Jool.nl

21 years ago
Hi Rob, Tank you for you extensive reply.
> -----Original Message----- > A few comments from eyeballing the patch: > > - Depending upon how much c14n functionality there is to be, > this might be better off as a standalone extension. This way > it wouldn't be dependant upon DOM (especially if PHP is built > without it) and allow it to work with simplexml alone. Take > xsl for example (although it requires dom to output a dom > document, it allows processing via simplexml input - as > simplexml has no concept of a document i allow any simplexml > element to be used that has a document and just use the > document from that node.
This is about all the C14n functionality there is. I agree with you on it being dependant upon DOM. Don't you think it's to little functionality for an extension on his own? I thought it would fit nicely into the DOM extension. And this way, it's bundled by default :).
> - Looking at the patch, you may want to change the optional > node argument to an array so that multiple nodes can be used > for the visibility test > > - node needs to be initialized to NULL other wise if none is > passed it most likely will crash. that being said, if none is > passed in you should probably test and use xmlC14NDocSaveTo > as it will run much faster as no callback would need to be run. > > - no need to dupe the xml output buffer content and then dupe > it again when creating a zval. would dupe the output buffer > straight into the zval. > > - str_inclusive_ns parameter is st as a string. This however > needs to allow to a list of strings since > inclusive_ns_prefixes is a xmlChar ** which will be iterated > to get all the prefixes. > > Thats pretty much what jumped out at me as I mentioned I have > only looked at the patch and havent played with it.
Thanks, I will look into those points.
> If you are really looking at implementing the xml-security > specs, you might want to think about just creating an > extension from the xmlsec library. Developng xmlsec is very > complicated (just check out the libxml mailing list as this > has been brought up before and people are always steered to > the xmlsec library). I had started a while back working on an > extension for this, but other than some early layout code I > haven't found the time to work on it, so before diving in > trying to write it from scratch you might want to check out > that library. > > http://www.aleksey.com/xmlsec/
I'm aware of the xmlsec lib from aleksey (that's where the C14n functions originally came from) and I have no intentions to re-invent the wheel, especially not when it's as complicated as the xmlsec lib :). I wrote the c14n patch as a practise to get familiar with libxml and php extensions (and C), but it also allows people to use it in PHP to start hacking some signature scripts (together with openSSL extension ofcourse). Could you send me your 'early layout code'? Regards, David