Re: Is there a way to extract list of bound IPs via stats socket ?

September 1, 2017, 10:20 am

≪ Previous: HTTP2 DATA frames with 0 length

On Fri, Sep 01, 2017 at 05:49:38PM +0200, Lukas Tribus wrote:
> Hello,
>
>
> Am 01.09.2017 um 15:46 schrieb Mariusz Gronczewski:
> > Hi,
> >
> > I've been working on a piece of code to announce IPs (via ExaBGP) only if:
> >
> > * HAProxy is running
> > * HAProxy actually uses a given IP
> > * a frontend with given IP is up for few seconds.
> >
> > I could do that via lsof but that's pretty processor-intensive.
>
> Not sure about the stats or admin socket, but why not use ss instead?
>
> Something like:
> sudo ss -tln '( sport = :80 or sport = :443 )'
>
> add "-p" if you need the PID.
>
> Should perform well enough.

I think it would not be too hard to add this feature to the CLI. We already
have "show cli socket" which lists the listening stats sockets. We could
reuse this code to list all listening sockets and not the just stats ones.
Maybe "show listeners [optional frontend]" or something like this ?

Just my two cents,
Willy

↧

Re: capture.req.uri max length?

September 1, 2017, 10:20 am

≫ Next: Re: Is there a way to extract list of bound IPs via stats socket ?

≪ Previous: Re: Is there a way to extract list of bound IPs via stats socket ?

Hi Philip,

On Fri, Sep 01, 2017 at 09:28:50AM -0400, Philip Seidel wrote:
> Is there a maximum length when using capture.req.uri? It appears that the
> value is truncated when approaching close to 1024 bytes. It appears to be
> 1020 from the tests I was running. I have attempted to reduce
> tune.maxrewrite to 1024 since tune.bufsize is 16k; however, it appears that
> this doesn't have any impact. Are there some other settings that need to
> be adjusted to ensure that the value is not truncated?

It was made configurable very recently in 1.8-dev but it's not backported.
Instead you may apply the other solution documented in the commit message :

commit 23e9e931284b44e9d06cca26ab13648873b4029b
Author: StÃ©phane Cottin <stephane.cottin@vixns.com>
Date: Thu May 18 08:58:41 2017 +0200

MINOR: log: Add logurilen tunable.

The default len of request uri in log messages is 1024. In some use
cases, you need to keep the long trail of GET parameters. The only
way to increase this len is to recompile with DEFINE=-DREQURI_LEN=2048.

This commit introduces a tune.http.logurilen configuration directive,
allowing to tune this at runtime.

Hoping this helps,
Willy

↧

Re: Is there a way to extract list of bound IPs via stats socket ?

September 1, 2017, 10:30 am

≫ Next: [PATCH] DOC: Add note about "* " prefix in CSV stats

≪ Previous: Re: capture.req.uri max length?

On Fri, 1 Sep 2017 17:49:38 +0200, Lukas Tribus <lukyt@gmx.net> wrote:

> Hello,
>
>
> Am 01.09.2017 um 15:46 schrieb Mariusz Gronczewski:
> > Hi,
> >
> > I've been working on a piece of code to announce IPs (via ExaBGP) only if:
> >
> > * HAProxy is running
> > * HAProxy actually uses a given IP
> > * a frontend with given IP is up for few seconds.
> >
> > I could do that via lsof but that's pretty processor-intensive.
>
> Not sure about the stats or admin socket, but why not use ss instead?
>
> Something like:
> sudo ss -tln '( sport = :80 or sport = :443 )'
>
> add "-p" if you need the PID.
>
> Should perform well enough.
>
Huh, interesting.

I just assumed it will be similiar speed no matter which tool I use to get that info but ss does that < 100 ms while lsof and netstat take ages:

time lsof -iTCP -sTCP:LISTEN >/dev/null

real 0m13.460s
user 0m0.201s
sys 0m12.897s

time netstat -l -n -t >/dev/null

real 0m43.439s
user 0m0.190s
sys 0m42.395s

time ss -tln '( sport = :80 or sport = :443 )' >/dev/null

real 0m0.032s
user 0m0.000s
sys 0m0.032s

Now I know why netstat is getting replaced instead of "just" fixed... thanks.

--
Mariusz Gronczewski, Administrator

Efigence S. A.
ul. Wołoska 9a, 02-583 Warszawa
T: [+48] 22 380 13 13
F: [+48] 22 380 13 14
E: mariusz.gronczewski@efigence.com <mailto:mariusz.gronczewski@efigence.com>

↧

[PATCH] DOC: Add note about "* " prefix in CSV stats

September 1, 2017, 10:30 am

≫ Next: Re: Enable SSL Forward Secrecy

≪ Previous: Re: Is there a way to extract list of bound IPs via stats socket ?

Just a little documentation patch I wrote, after stumbling across this:

https://github.com/dschneller/bosun/commit/6ca776dd6543d123a135b4a84a5e3e66093c3986

Cheers,
Daniel

--
Daniel Schneller
Principal Cloud Engineer

CenterDevice GmbH | Hochstraße 11
| 42697 Solingen
tel: +49 1754155711 | Deutschland
daniel.schneller@centerdevice.de | www.centerdevice.de

Geschäftsführung: Dr. Patrick Peschlow, Dr. Lukas Pustina,
Michael Rosbach, Handelsregister-Nr.: HRB 18655,
HR-Gericht: Bonn, USt-IdNr.: DE-815299431

↧

Re: Enable SSL Forward Secrecy

September 1, 2017, 10:50 am

≫ Next: Re: Enable SSL Forward Secrecy

≪ Previous: [PATCH] DOC: Add note about "* " prefix in CSV stats

Hi,

inspired by this, I added a paragraph with links to the documentation.
Small patch attached.

Cheers,
Daniel

--
Daniel Schneller
Principal Cloud Engineer

CenterDevice GmbH | Hochstraße 11
| 42697 Solingen
tel: +49 1754155711 | Deutschland
daniel.schneller@centerdevice.de | www.centerdevice.de

Geschäftsführung: Dr. Patrick Peschlow, Dr. Lukas Pustina,
Michael Rosbach, Handelsregister-Nr.: HRB 18655,
HR-Gericht: Bonn, USt-IdNr.: DE-815299431

> On 1. Sep. 2017, at 19:05, Willy Tarreau <w@1wt.eu> wrote:
>
> On Fri, Sep 01, 2017 at 07:04:36PM +0200, Willy Tarreau wrote:
>> Hi Cyril,
>
> s/Cyril/Lukas, sorry guys, that's what happens when I read one e-mail
> and reply to another one at the same time :-)
>
> Willy

↧

Re: Enable SSL Forward Secrecy

September 1, 2017, 11:00 am

≫ Next: RE: Enable SSL Forward Secrecy

≪ Previous: Re: Enable SSL Forward Secrecy

On Fri, Sep 01, 2017 at 07:37:50PM +0200, Daniel Schneller wrote:
> Hi,
>
> inspired by this, I added a paragraph with links to the documentation.
> Small patch attached.

Cool, thanks Daniel, now applied.

Willy

↧

RE: Enable SSL Forward Secrecy

September 1, 2017, 11:40 am

≫ Next: Re: capture.req.uri max length?

≪ Previous: Re: Enable SSL Forward Secrecy

Hi,

I recently started receiving the emails for JGronowski@ditronics.com, can you please remove this name from whatever list this is?

Regards,

Rachel Davis
IT Help Desk

7699 W. Post Road
Las Vegas, NV 89113
Mobile: 702.600.0472
Customer Service: 800.845.3065
Website: www.ditronics.com

-----Original Message-----
From: Willy Tarreau [mailto:w@1wt.eu]
Sent: Friday, September 1, 2017 10:55 AM
To: Daniel Schneller <daniel.schneller@centerdevice.com>
Cc: Lukas Tribus <lukyt@gmx.net>; Julian Zielke <jzielke@next-level-integration.com>; Cyril Bonté <cyril.bonte@free.fr>; haproxy+help@formilux.org <haproxy@formilux.org>
Subject: Re: Enable SSL Forward Secrecy

On Fri, Sep 01, 2017 at 07:37:50PM +0200, Daniel Schneller wrote:
> Hi,
>
> inspired by this, I added a paragraph with links to the documentation.
> Small patch attached.

Cool, thanks Daniel, now applied.

Willy

Ditronics, LLC email disclaimer:
This communication, including attachments, is intended only for the exclusive use of addressee and may contain proprietary, confidential, or privileged information. Any use, review, duplication, disclosure, dissemination, or distribution is strictly prohibited. If you were not the intended recipient, you have received this communication in error. Please notify sender immediately by return e-mail, delete this communication, and destroy any copies.

↧

Re: capture.req.uri max length?

September 1, 2017, 11:50 am

≫ Next: [PHP] Migrating from PHP 7.1.9 RC 1 to PHP 7.1.9 shuts down Maria DB 10.2.7

≪ Previous: RE: Enable SSL Forward Secrecy

Thanks Willy! That worked perfectly.

Phil

On Fri, Sep 1, 2017 at 1:12 PM, Willy Tarreau <w@1wt.eu> wrote:

> Hi Philip,
>
> On Fri, Sep 01, 2017 at 09:28:50AM -0400, Philip Seidel wrote:
> > Is there a maximum length when using capture.req.uri? It appears that
> the
> > value is truncated when approaching close to 1024 bytes. It appears to
> be
> > 1020 from the tests I was running. I have attempted to reduce
> > tune.maxrewrite to 1024 since tune.bufsize is 16k; however, it appears
> that
> > this doesn't have any impact. Are there some other settings that need to
> > be adjusted to ensure that the value is not truncated?
>
> It was made configurable very recently in 1.8-dev but it's not backported..
> Instead you may apply the other solution documented in the commit message :
>
> commit 23e9e931284b44e9d06cca26ab13648873b4029b
> Author: Stéphane Cottin <stephane.cottin@vixns.com>
> Date: Thu May 18 08:58:41 2017 +0200
>
> MINOR: log: Add logurilen tunable.
>
> The default len of request uri in log messages is 1024. In some use
> cases, you need to keep the long trail of GET parameters. The only
> way to increase this len is to recompile with DEFINE=-DREQURI_LEN=2048.
>
> This commit introduces a tune.http.logurilen configuration directive,
> allowing to tune this at runtime.
>
> Hoping this helps,
> Willy
>

↧

[PHP] Migrating from PHP 7.1.9 RC 1 to PHP 7.1.9 shuts down Maria DB 10.2.7

September 1, 2017, 1:30 pm

≫ Next: Re: HTTP2 DATA frames with 0 length

≪ Previous: Re: capture.req.uri max length?

All right. Can I have the diff files for

PHP 7.1.9RC1 to 7.1.9 ?

My MAriaDB 10.2.7 coked and choke not link properly to PHP 7.1.9 .
--
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising!
https://www.empire.kred/ROOTNK?t=94a1f39b Look at Psalms 14 and 53 on Atheism
Talk Sense to a fool and he calls you foolish - Euripides

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

↧

Re: HTTP2 DATA frames with 0 length

September 1, 2017, 1:40 pm

≫ Next: Re: [PHP] Migrating from PHP 7.1.9 RC 1 to PHP 7.1.9 shuts down Maria DB 10.2.7

≪ Previous: [PHP] Migrating from PHP 7.1.9 RC 1 to PHP 7.1.9 shuts down Maria DB 10.2.7

On пятница, 1 сентября 2017 г. 19:59:04 MSK Muhui Jiang wrote:
> Hi
>
> I am using nginx 1.9.15. I noticed when I made a HTTP2 request to the
> nginx. It will send the data frames that carry the object first. But end
> with a data frame whose length is zero indicating the Data end flag.
>
> I am curious why you guys design in this way. I think we don't need this
> extra data frame. Maybe nginx has already fix this, If so, could you tell
> me the exact version.. Many Thanks
>

Request processing in nginx is quite complex. There may have many data
sources, modules, filter modules, and so on. The HTTP/2 module works quite
straightforward, if it sees the end of buffer chain in nginx, it adds the
END_STREAM flag. Otherwise, it doesn't.

So, whether you see END_STREAM in a separate DATA frame or not depends on
many factors and your configuration.

wbr, Valentin V. Bartenev

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

↧

Re: [PHP] Migrating from PHP 7.1.9 RC 1 to PHP 7.1.9 shuts down Maria DB 10.2.7

September 1, 2017, 2:10 pm

≫ Next: Re: [PHP] Migrating from PHP 7.1.9 RC 1 to PHP 7.1.9 shuts down Maria DB 10.2.7

≪ Previous: Re: HTTP2 DATA frames with 0 length

On Fri, Sep 1, 2017 at 2:26 PM, The Doctor <doctor@doctor.nl2k.ab.ca> wrote:

>
> All right. Can I have the diff files for
>

https://github.com/php/php-src/compare/php-7.1.9RC1...php-7.1.9

Note: On github you can always do
github.com/user/project/compare/tagA...tagB the key being that last part
where we add /compare to the project url, from there we can put any commit
hash, branch name or tag followed by three dots followed by the hash,
branch or tag you'd like to compare against.

>
> PHP 7.1.9RC1 to 7.1.9 ?
>
> My MAriaDB 10.2.7 coked and choke not link properly to PHP 7.1.9 .
> --
> Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@
> nl2k.ab.ca
> Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist
> rising!
> https://www.empire.kred/ROOTNK?t=94a1f39b Look at Psalms 14 and 53 on
> Atheism
> Talk Sense to a fool and he calls you foolish - Euripides
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

↧

Re: [PHP] Migrating from PHP 7.1.9 RC 1 to PHP 7.1.9 shuts down Maria DB 10.2.7

September 1, 2017, 3:00 pm

≫ Next: [PHP-DEV] GOOD Benchmark Results for PHP Master 2017-08-31

≪ Previous: Re: [PHP] Migrating from PHP 7.1.9 RC 1 to PHP 7.1.9 shuts down Maria DB 10.2.7

On Fri, Sep 01, 2017 at 03:04:50PM -0600, Ryan Pallas wrote:
> On Fri, Sep 1, 2017 at 2:26 PM, The Doctor <doctor@doctor.nl2k.ab.ca> wrote:
>
> >
> > All right. Can I have the diff files for
> >
>
> https://github.com/php/php-src/compare/php-7.1.9RC1...php-7.1.9
>
> Note: On github you can always do
> github.com/user/project/compare/tagA...tagB the key being that last part
> where we add /compare to the project url, from there we can put any commit
> hash, branch name or tag followed by three dots followed by the hash,
> branch or tag you'd like to compare against.
>

I will try.

When I see

mysqli_get_server_info()

mysqli_query()

and

mysqli_select()

Invalid object or resource mysqli in

....

I sense a patch has ruined the whole php!

>
> >
> > PHP 7.1.9RC1 to 7.1.9 ?
> >
> > My MAriaDB 10.2.7 coked and choke not link properly to PHP 7.1.9 .
> > --
> > Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@
> > nl2k.ab.ca
> > Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist
> > rising!
> > https://www.empire.kred/ROOTNK?t=94a1f39b Look at Psalms 14 and 53 on
> > Atheism
> > Talk Sense to a fool and he calls you foolish - Euripides
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >

--
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising!
https://www.empire.kred/ROOTNK?t=94a1f39b Look at Psalms 14 and 53 on Atheism
Talk Sense to a fool and he calls you foolish - Euripides

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

↧

[PHP-DEV] GOOD Benchmark Results for PHP Master 2017-08-31

September 1, 2017, 3:50 pm

≫ Next: [SPAM]

≪ Previous: Re: [PHP] Migrating from PHP 7.1.9 RC 1 to PHP 7.1.9 shuts down Maria DB 10.2.7

Results for project PHP master, build date 2017-08-31 19:23:33-07:00
commit: 4cb06b9
previous commit: ce10a98
revision date: 2017-08-31 23:58:19+02:00
environment: Haswell-EP
cpu: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB
mem: 128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0, with hash 60fffd2 from
2015-12-01 04:16:47+00:00

-------------------------------------------------------------------------------------------
benchmark relative change since change since current rev run
std_dev* last run baseline with PGO
-------------------------------------------------------------------------------------------
:-| Wordpress 4.2.2 cgi -T10000 0.25% 0.11% 4.07% 9.02%
:-| Drupal 7.36 cgi -T10000 0.16% 0.10% 3.95% 5.50%
:-| MediaWiki 1.23.9 cgi -T5000 0.13% 0.45% 5.22% 3.50%
:-| bench.php cgi -T100 0.01% 0.05% 45.33% -0.46%
:-) micro_bench.php cgi -T10 0.01% 1.08% 29.15% 2.70%
:-) mandelbrot.php cgi -T100 0.01% 4.42% 45.27% 0.69%
-------------------------------------------------------------------------------------------

* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: http://languagesperformance.intel.com/good-benchmark-results-for-php-master-2017-08-31/

Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
More details on measurements methodology at:
https://01.org/lp/documentation/php-environment-setup.

Subject Label Legend:
Attributes are determined based on the performance evolution of the workloads
compared to the previous measurement iteration.
NEUTRAL: performance did not change by more than 1% for any workload
GOOD: performance improved by more than 1% for at least one workload and there
is no regression greater than 1%
BAD: performance dropped by more than 1% for at least one workload and there is
no improvement greater than 1%
UGLY: performance improved by more than 1% for at least one workload and also
dropped by more than 1% for at least one workload

Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

↧

[SPAM]

September 1, 2017, 5:00 pm

≫ Next: GSMA Mobile World Congress Americas 2017- Attendees list

≪ Previous: [PHP-DEV] GOOD Benchmark Results for PHP Master 2017-08-31

By far, my absolute favorite part of making money using affiliate programs is the freedom it comes with. I can work from anywhere I want, whenever I want, with whome I want, as hard as I want, and I call all the shots.I’ve been traveling the United States since 2009 working on this business and absolutely love that I can work from anywhere.reading more here all info

↧

GSMA Mobile World Congress Americas 2017- Attendees list

September 1, 2017, 5:40 pm

≫ Next: Re: HTTP2 DATA frames with 0 length

≪ Previous: [SPAM]

Hi,

Hope this note finds you good

I understand that you are one of the Exhibitor of upcoming event "GSMA
Mobile World Congress Americas 2017" which is held on September 12th - 14th
San Francisco|USA.

I thought I'd check if you are interested in acquiring "GSMA Mobile World
Congress Americas 2017- Prospective Visitors List" for pre-show marketing
campaign, Appointment Setting, Networking and various Marketing initiative.

If you are interested, drop me a line. We will get back to you with pricing,
counts and other information for your review.

Thank you and I look forward to hear from you soon!

Regards,

Jerry Jones | Inside Sales|

"If you don't wish to receive email from us please reply back with LEAVE
OUT"

↧

Re: HTTP2 DATA frames with 0 length

September 1, 2017, 11:00 pm

≫ Next: [PHP-DEV] [VOTE] UUID

≪ Previous: GSMA Mobile World Congress Americas 2017- Attendees list

Hi Valentin

Thanks for your email.

if it sees the end of buffer chain in nginx, it adds the END_STREAM flag
========================
Here the buffer chain means the ssl buffer?

The thing I am curious is that why nginx need to carry a data frame whose
payload length is zero. Nginx could add the END_STREAM flag in the previous
DATA frame.
Since I am doing some research work using nginx. I hope that the nginx only
return one DATA frame to me when I request an object. However, No matter
how small the object size is, nginx will always add an extra DATA frame
whose length is zero plus an END_STREAM flag. Do you have any suggestions
or could you please propose a configuration that NGINX will only return one
DATA frame for one stream. Many thanks

Regards
Muhui

2017-09-02 4:32 GMT+08:00 Valentin V. Bartenev <vbart@nginx.com>:

> On пятница, 1 сентября 2017 г. 19:59:04 MSK Muhui Jiang wrote:
> > Hi
> >
> > I am using nginx 1.9.15. I noticed when I made a HTTP2 request to the
> > nginx. It will send the data frames that carry the object first. But end
> > with a data frame whose length is zero indicating the Data end flag.
> >
> > I am curious why you guys design in this way. I think we don't need this
> > extra data frame. Maybe nginx has already fix this, If so, could you tell
> > me the exact version.. Many Thanks
> >
>
> Request processing in nginx is quite complex. There may have many data
> sources, modules, filter modules, and so on. The HTTP/2 module works quite
> straightforward, if it sees the end of buffer chain in nginx, it adds the
> END_STREAM flag. Otherwise, it doesn't.
>
> So, whether you see END_STREAM in a separate DATA frame or not depends on
> many factors and your configuration.
>
> wbr, Valentin V. Bartenev
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

↧

[PHP-DEV] [VOTE] UUID

September 2, 2017, 12:10 am

≫ Next: Re: [PHP-DEV] [VOTE] UUID

≪ Previous: Re: HTTP2 DATA frames with 0 length

Hello Internals!

I just started the voting for the inclusion of a UUID value object in
PHP's core, targeting PHP 7.3. I wanted to start earlier, but was sick
the whole week.

The voting is open starting now and until September 16. (2 weeks).

--
Richard "Fleshgrinder" Fussenegger

↧

Re: [PHP-DEV] [VOTE] UUID

September 2, 2017, 12:40 am

≫ Next: Re: [PHP-DEV] [VOTE] UUID

≪ Previous: [PHP-DEV] [VOTE] UUID

>
> Hello Internals!
>
> I just started the voting for the inclusion of a UUID value object in
> PHP's core, targeting PHP 7.3. I wanted to start earlier, but was sick
> the whole week.
>
> The voting is open starting now and until September 16. (2 weeks).

RFC: https://wiki.php.net/rfc/uuid

↧

Re: [PHP-DEV] [VOTE] UUID

September 2, 2017, 12:40 am

≫ Next: RE: [PHP-DEV] [VOTE] UUID

≪ Previous: Re: [PHP-DEV] [VOTE] UUID

On 9/2/2017 9:32 AM, Niklas Keller wrote:
>>
>> Hello Internals!
>>
>> I just started the voting for the inclusion of a UUID value object in
>> PHP's core, targeting PHP 7.3. I wanted to start earlier, but was sick
>> the whole week.
>>
>> The voting is open starting now and until September 16. (2 weeks).
>
>
> RFC: https://wiki.php.net/rfc/uuid
>

This is the second time that I forget the link, stupid me. Thanks a lot. :)

--
Richard "Fleshgrinder" Fussenegger

↧

RE: [PHP-DEV] [VOTE] UUID

September 2, 2017, 3:20 am

≫ Next: Re: [PHP-DEV] [VOTE] UUID

≪ Previous: Re: [PHP-DEV] [VOTE] UUID

I just voted 'no', and I'd like to quickly explain why:

0. I agree with the premise of the RFC, that we should have something better than uniqid() built into the language.
1. I think a renewed discussion, beyond the two days of discussion 3+ months ago would be useful, as beyond that basic (yet important) point - I have thoughts about a bunch of things in the RFC, and honestly didn't even notice the brief discussion months ago (if there was another one then my apologies, I couldn't find it).
2. I think that a function that returns a string (a-la uuid_v4_create() Nikita proposed) would make perfect sense. Forcing the use of classes/objects in such a case - where there's little to no added value, is wrong and uncommon (possibly unprecedented) in PHP.
3. The section dealing with backwards incompatible changes, states:
"Both UUID and UUIDParseException are now globally defined classes, which might collide with user defined classes of the same name in the global namespace. However, the risk of the introduction of them is considered to be very low, since the global namespace should not be used by PHP users."
... erroneously assumes that all code in PHP utilizes namespaces. IMHO this is a projection of a particular coding style onto the entire PHP userbase. We haven't deprecated at any point the ability to place user classes in the global namespace, we haven't even as much as said at any point we might be considering it - and I don't think we should, either. My gut feel, backed by a quick Google search refutes the assumption that the risk of introducing - at least the UUID class - is very low. Not that I have a better suggestion (other than not introducing a class at all) - but I think the text there should be changed as it does not reflect reality.
4. If I voted yes, it would also mean I agree with a statement such as "One could argue that it is faster (C implementation), which it probably is, but this is a weak argument". I disagree it's a weak argument - and I do think that for basic building blocks of the language, performance absolutely matters. If we manage to get JIT out the door and the performance differences become negligible - then I see a lot of value in moving some of our core value to PHP - but not before then.
5. Given we seem to agree this is a basic building block of the language (as it is in other languages), I do think it should be a 2/3 majority vote and not a 50%+1 one. Taking the "is this something we can easily change w/o affecting BC" test, this clearly gets a 'no'.

To summarize - I'm strongly in favor of fixing this issue in PHP, but at the same time against the proposed solution. I'd vote in favor of something along the lines of uuid_v4_create() in a heartbeat.

Zeev

-----Original Message-----
From: Fleshgrinder [mailto:php@fleshgrinder.com]
Sent: שבת 02 ספטמבר 2017 10:02
To: php-internals <internals@lists.php.net>
Subject: [PHP-DEV] [VOTE] UUID

Hello Internals!

I just started the voting for the inclusion of a UUID value object in PHP's core, targeting PHP 7.3. I wanted to start earlier, but was sick the whole week.

The voting is open starting now and until September 16. (2 weeks).

--
Richard "Fleshgrinder" Fussenegger

↧

Latest Images