Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91055
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
To: "'Dmitry Stogov'" <dmitry@zend.com>,
	<internals@lists.php.net>
Cc: "'Pierre Joye'" <pierre.php@gmail.com>,
	"'Xinchen Hui'" <laruence@gmail.com>,
	"'Nikita Popov'" <nikita.ppv@gmail.com>
References: <03ca01d159da$fe2d76b0$fa886410$@belski.net> <56AF2410.3090009@zend.com> <006301d15cd7$c60fe6f0$522fb4d0$@belski.net>
In-Reply-To: <006301d15cd7$c60fe6f0$522fb4d0$@belski.net>
Date: Tue, 2 Feb 2016 08:27:24 +0100
Message-ID: <01ec01d15d8b$2bb58a10$83209e30$@belski.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AQHc/OH61fGL/otFQ0yoa3ZjD19IYAFPI2IiAqgwWrye4VfkQA==
Content-Language: en-us
Subject: RE: [PHP-DEV] Re: Streams and I/O refactoring approach
From: anatol.php@belski.net ("Anatol Belski")

Hi,

> -----Original Message-----
> From: Anatol Belski [mailto:anatol.php@belski.net]
> Sent: Monday, February 1, 2016 11:03 AM
> To: 'Dmitry Stogov' <dmitry@zend.com>; internals@lists.php.net
> Cc: 'Pierre Joye' <pierre.php@gmail.com>; 'Xinchen Hui'
> <laruence@gmail.com>; 'Nikita Popov' <nikita.ppv@gmail.com>
> Subject: RE: [PHP-DEV] Re: Streams and I/O refactoring approach
> 
> 
> Hi Dmitry,
> 
> Many thanks for the comments.
> 
> > -----Original Message-----
> > From: Dmitry Stogov [mailto:dmitry@zend.com]
> > Sent: Monday, February 1, 2016 10:23 AM
> > To: Anatol Belski <anatol.php@belski.net>; internals@lists.php.net
> > Cc: 'Pierre Joye' <pierre.php@gmail.com>; 'Xinchen Hui'
> > <laruence@gmail.com>; 'Nikita Popov' <nikita.ppv@gmail.com>
> > Subject: [PHP-DEV] Re: Streams and I/O refactoring approach
> >
> > Hi,
> >
> > At current state, I see this not as a whole stream layer refactoring,
> > but
> as a low-
> > level replacement of POSIX layer on Windows.
> > I see only few "visible" changes:
> >
> Basically it's the result of analyzing the code of particularly APR, libuv
and
> several other projects. While libuv works with UTF-8 paths only, APR
retains a
> wider compatibility. Please check the code here for an example
> 
> https://github.com/apache/apr/blob/trunk/file_io/win32/open.c#L321
> 
> > 1. The layer first checks, if file names are valid UTF-8 strings, and
> > use
> UTF-8
> > names or fall back to system locale.
> Yep, it is done for the fallback, and also the non-unicode part is
conditional, so
> can be turned off on compilation time with
> PHP_WIN32_IOUTIL_ANSI_COMPAT_MODE set to 0. For an example how it is
> done in APR
> 
> https://github.com/apache/apr/blob/trunk/file_io/win32/open.c#L406
> 
> Currently it would make sense to keep this fallback, so the current
scripts/codes
> using non-unicode would keep to work.
> 
> > 2. The patch allows to use long file names (longer than MAX_PATH)
> > using "//?/******<utf8-absolute-long-path>"
> Yep, to do is to prepend \\?\ transparently for the user. But even without
\\?\
> multibyte paths are supported.
> 
> > 3. Files now are opened in FILE_SHARE_READ | FILE_SHARE_WRITE |
> > FILE_SHARE_DELETE mode (I'm not sure about intended better POSIX
> > compliance and possible side effects).
> >
> This is done in most projects, fe
> 
> https://github.com/apache/apr/blob/trunk/file_io/win32/open.c#L346
> 
> But we can remove it if there's something wrong.
> 
> > For me, the approach looks a bit inconsistent, especially the attempt
> > to
> use the
> > same string as UTF-8 and then using some code page.
> >
> 
> The only difference of my approach to the other projects is that I suggest
to
> keep the POSIX compatible APIs, instead of having a whole scruct
describing a
> filesystem object, fe
> 
> https://ci.apache.org/projects/httpd/trunk/doxygen/structapr__file__t.html
> 
> It could be done later, but for now keeping POSIX APIs would be IMHO the
> simplest solution. And as I've stated, it is just a preparation to have
everything at
> the same base, otherwise further improvements are quite tedious.
> 
After some discussions and rethinking this approach, I came to conclusion
that creating a layer with POSIX compatible signatures for low level IO is
most likely not a good idea. I won't continue on this idea and rather going
for an RFC to target better APIs and refactoring for the low level IO layer.
Though probably it were worth to reuse the parts of this patch to add the
missing features in the current code base.

Thanks.

Anatol