Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71291
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.54 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
Date: Mon, 20 Jan 2014 12:10:35 +0900
Message-ID: <CAGa2bXar-V3UbQUGrK8_BPPeFr75WhE2ryKLtB6riTSc3tkrQQ@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113496aaaa0fbe04f05e3ec0
Subject: [RFC] mbstring-ng
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a113496aaaa0fbe04f05e3ec0
Content-Type: text/plain; charset=UTF-8

Hi all,

I would like to discuss RFC created at 2009 by Moriyoshi.

Alternative mbstring implementation using ICU
https://wiki.php.net/rfc/altmbstring

The reason behind of this RFC is library used by mbstring.
mbstring uses libmbfl for multibyte string handling and Oniguruma
for multibyte regular expression.

libmbfl is not used widely AFAIK. Oniguruma is used widely by Ruby, etc.
Issue for these libraries are license. They are LGPLed. As long as
PHP/mbstring or
embed SAPI is used as shared library, users are not affected by LGPL.
However,
if users compile their extension statically into PHP or use embed SAPI
statically,
they are affected by LGPL.

I would like to introduce mbstring-ng as a replacement of mbstring for PHP
6 and
move mbstring to PECL. It may be good to introduce work in progress
mbstring-ng
to PHP 5.6 as EXPERIMENTAL module for further development and testing.

There would be compatibility issues between mbstring-ng and mbstring due to
the
difference of used library. Even if there would be compatibility issues,
adoption of
mbstring-ng is better for future development. IMHO.

Any comments?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a113496aaaa0fbe04f05e3ec0--