Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:41992 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 27324 invoked from network); 19 Nov 2008 05:30:54 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 19 Nov 2008 05:30:54 -0000 Authentication-Results: pb1.pair.com smtp.mail=mark@hell.ne.jp; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=mark@hell.ne.jp; sender-id=pass Received-SPF: pass (pb1.pair.com: domain hell.ne.jp designates 84.96.92.120 as permitted sender) X-PHP-List-Original-Sender: mark@hell.ne.jp X-Host-Fingerprint: 84.96.92.120 neuf-infra-smtp-out-sp604007av.neufgp.fr Received: from [84.96.92.120] ([84.96.92.120:59167] helo=neuf-infra-smtp-out-sp604007av.neufgp.fr) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 13/C0-21290-B84A3294 for ; Wed, 19 Nov 2008 00:30:53 -0500 Received: from neuf-infra-smtp-out-sp604011av.neufgp.fr ([10.110.56.116]) by neuf-infra-smtp-out-sp604007av.neufgp.fr with neuf telecom id gb1F1a00c2WT6TN07tWprF; Wed, 19 Nov 2008 06:30:49 +0100 Received: from [192.168.0.25] ([77.207.3.30]) by neuf-infra-smtp-out-sp604011av.neufgp.fr with neuf telecom id gtWo1a0090erKVH0BtWojU; Wed, 19 Nov 2008 06:30:49 +0100 To: Andrei Zmievski Cc: Lukas Kahwe Smith , internals@lists.php.net In-Reply-To: <49235C81.2030307@gravitonic.com> References: <49235C81.2030307@gravitonic.com> Content-Type: text/plain; charset=utf-8 Date: Wed, 19 Nov 2008 06:30:48 +0100 Message-ID: <1227072648.14940.70.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] CVS Account Request: magicaltux From: mark@hell.ne.jp (Mark) Hi, I believe Andrei's also OK with the solution for this bug. As he said when one of my colleagues went to a PHP conference (I couldn't this day for personnal reasons), "English is not the only language". Having an hardcoded encoding for the "php-side of life" is bad, we could either make this a php.ini entry (or use a php.ini entry), or stick with the way most xml functions are done in PHP (only accept UTF-8, that's what my patch does). Encoding non utf-8 valid data to base64 (WDDX "binary" type) would be the best option, the only problem is the overhead of doing this (maybe people have a need for transmission of binary data, but for now the PHP WDDX extension isn't able to manage that, it's something else I'd like to fix, and encoding everything from "ISO-8859-1" is not a solution). For reference: http://bugs.php.net/46496 So, unless someone have time to bear with me and commit my stuff to WDDX (I've already started some things for WDDX packet streaming, but anyway 5.2.7 isn't at a point it will accept any new features) I confirm my request for a CVS account with the ability to edit ext/wddx/ and I hope to be able to fix bug #46496 before 5.2.7 release. Best regards, Mark Karpeles Le mardi 18 novembre 2008 à 16:23 -0800, Andrei Zmievski a écrit : > Lukas Kahwe Smith wrote: > >> I also intend later (and after some discussions, if anyone has any > >> interest in WDDX) to add a feature to WDDX to provide the ability to > >> stream a packet (create a packet ressource while providing a stream > >> descriptor, send the XML code for the variables when added, then close > >> the packet with an "end of packet" instruction). Providing the reverse > >> process would also have to be done at the same time, using event-based > >> xml parsing. > >> This would allow memory-efficient creation of large packets. > > > > > > Andrei is the maintainer for the WDDX extension. > > Could you give Mark some feedback here? > > I think that would be a good feature. > > -Andrei >