Re: [PHP-DEV] Adding a donate link to the PHP website
On Sat, Dec 2, 2023, at 1:32 AM, Rowan Tommins wrote: > The only note of caution I would throw in is that the recent Technical > Committee proposal [1] was soundly rejected, so any *organisational* changes > are likely to be a lot more contentious. So care should be taken to separate > those from purely legal or financial links. > > [1] https://wiki.php.net/rfc/php_technical_committee I think a very important distinction to be made is in replacing/reforming the PHP Group is that it should be seen solely as a group that manages the non-technical aspects of the PHP project, which makes it very different from this Technical Committee proposal. Jim -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [PDO] 2 phase commit
Hi Eugene. > 1. We have sent commit to the first database and it responded us with OK > (comitted) > 2. Next we send commit to the second database, and it may be the case that in > that very moment we lose connection. Hence, if connection is lost before > final commit request, second database won't receive commit, and since It's > not aware of whether transaction should be committed or rolled back, data is > never made persistent. > > FWIK, this case is usually handled at the application level using async > commit in message consumers. Meaning commit operation will be retied again, > and again, and again until the connection is restored. > > Therefore, commit point is the point of no-return and network issues is the > problem we have to deal with. This point highlights a critical and common challenge in deciding whether to commit to a database. Moreover, this consideration applies broadly to any side effects on external systems, not solely to databases or two-phase commits. Since the solution method differs depending on the system requirements and specifications, I think developers should ensure safety through their own implementation, and in other words, there is no need to consider it as a capability of PHP itself. Consider, for instance more generally, the following scenarios where unintended loss of connectivity and processing interruptions are critical. * Send multiple HTTP requests with side-effects to external APIs at the same time. If the connection is lost before the response is returned. * Processes that acquire locks, such as by creating a file in the filesystem, rather than using locks from RDBMS, Redis, etc. If the process is terminated abnormally by the OS while locked, it becomes difficult to determine if the file's presence is due to an unfinished process or an abnormal termination. In both scenarios, consistency will be checked using another process equivalent to the message consumers you mentioned, or some other method. In the case of a two-phase commit as well, I think that PHP itself MAY do nothing (or SHOULD NOT do anything). Regarts. Kentaro Takeda -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Adding a donate link to the PHP website
Nicolas Grekas wrote: >There's one important piece missing in your analysis: > >https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#6-contributions-under-repository-license Note the second paragraph there: > Isn't this just how it works already? Yep. This is widely accepted as the > norm in the open-source community; it's commonly referred to by the shorthand > "inbound=outbound". We're just making it explicit. My reading of Ben's analysis is that not only is this widely accepted by the community, it's widely accepted by the legal system as well. So contributing via GitHub isn't doing anything extra here, they're just reminding their users, like statements of "all rights reserved" or "this does not affect your statutory rights". As to the main thrust of the thread: I agree with Larry's last email: both donation and licensing changes seem sensible steps forward. The only note of caution I would throw in is that the recent Technical Committee proposal [1] was soundly rejected, so any *organisational* changes are likely to be a lot more contentious. So care should be taken to separate those from purely legal or financial links. [1] https://wiki.php.net/rfc/php_technical_committee Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
