Features and Extensions to be Removed from PHP 7 - Lately in PHP podcast episode 57

Contents

Introduction (0:20)

PHP 5.4.38 and 5.5.22, PHP 5.6.6 released (1:24)

Removal of Dead SAPI (Web server APIs) and Extensions From PHP 7 (3:59)

Enable opcache by default in PHP 7? (21:34)

Caching PHP opcode Read from Streams (25:20)

PHP Parser Extension API (28:01)

Zend Discloses their Open Source JIT Engine (30:14)

How to Check if an OAuth Token is Valid? (36:29)

JavaScript Innovation Award Winners of December 2014 (40:05)

JavaScript Innovation Award Championship Rankings (43:24)

PHP Innovation Award Winners of December 2014 (44:18)

PHP Innovation Award Championship Rankings (49:13)

Conclusion (50:56)

Contents

Listen or download the podcast, RSS feed and subscribe in iTunes

Watch the podcast video, subscribe to the podcast YouTube channel

Read the podcast transcript

Introduction (0:20)

[Music]

Manuel Lemos: Hello. Welcome to the Lately in PHP podcast. This is episode 57. My webcam is not working this month. That's a shame. Better for Arturs Sosins... as usual, he is here with us to help commenting about the latest events in the PHP world.

Hello, Arturs, how are you doing?

Arturs Sosins: Hello. And I also fill the screen with my face because they can't see yours.

Manuel Lemos: OK, that's good to know. Unfortunately, my webcam refused to work in any computer that I have. It's some bad luck. But anyway, I guess the world is not here to watch my face. It's just to listen to us to comment about the latest happenings, events, developments in the PHP world.

PHP 5.4.38 and 5.5.22, PHP 5.6.6 released (1:24)

Manuel Lemos: So we're going to start as always from...

Arturs Sosins: Yeah, basically, we can watch your screen, right?

Manuel Lemos: Yeah, I think so. Not that I have tried, but now that you ask, I'm on it. So let me start with the usual releases of PHP. I guess you can see my screen now.

First, they are basically maintenance releases for PHP 5.4, in this case, .38. PHP 5.4 is in security releases mode. All the bugs that were fixed are related with security. So we have seen several bugs being fixed. Some may or may not affect your PHP environment, so if you are using PHP 5.4, you should take a look at these bugs that were fixed and see if they affect you.

It's always good to upgrade if you are using this PHP release, but if you are worried it may break something, you should always test it for a while, as always.

And for PHP 5.5 and 5.6... there is the 5.5.22 and 5.6.6... these are releases that not only have the security bugs fixed, but also some small enhancements, small bugs that are not related with security too. But overall, I do not see anything really worth commenting as usual.

So it's just heads up for everybody that upgrade... Sorry?

Arturs Sosins: No new features, just maintenance.

Manuel Lemos: Yeah, well, there are... I don't know if you can call these features because... Yeah, there are general improvements, because these are maintenance releases. And I think we'll have at least one of these maintenance releases for all these versions until PHP 7 is released hopefully later this year.

Removal of Dead SAPI (Web server APIs) and Extensions From PHP 7 (3:59)

Manuel Lemos: So given that, let's move on to the series of topics that we cover about the PHP world, namely proposals and discussions about features.

It seems that February has been quite intense in terms of discussions about things that should be removed from PHP 7, I mean features that were present in past versions. But there are lots of other discussions.

The type hinting discussion still goes on, but since we covered it last month we're not going back to that because there is not yet a satisfactory decision for many of the people that wanted to have scalar type hinting.

So we're going to comment, as I mentioned, about these proposals to remove features. In this case, we start about this proposal that talks about removing dead or not yet ported extensions and SAPIs.

SAPIs are sort of extension that allow PHP to interface with different Web servers or environment like the CLI and so on.

This proposal lists lots of apparently dead SAPIs. SAPIs are, as I mentioned, interfaces to several Web servers. I don't know if it is worth to cover each one of these one by one. Here, we see Apache 1. Yes?

Arturs Sosins: Yeah, exactly. I just want to point out...

Manuel Lemos: I don't think...

Arturs Sosins: I just wanted to point out that that's Apache 1, and Apache 2 is still supported, so nothing to worry there.

Manuel Lemos: Well, there is a mode of Apache 2 which is apache2filter which is also being considered as dead. Well, not really dead but broken, that's what they say.

Then, there are several others. This ISAPI, I think, it's the extension to the Microsoft IIS. But since even Microsoft switched to support FastCGI, I think nobody's concerned about using this ISAPI. I think it was not really stable.

Apart from that, there is also a list of extensions here below. Some extensions, they said to be with unmaintained dependencies, which means that they rely on external libraries for which the developers are now no longer working on them.

So they are concerned that somebody discovers security problems and nobody is there to fix them, so they are concerned to keep these extensions.

Other than that, there are several database extensions mentioned here below because they were not yet ported, and probably some of them are not going to be ported because nobody is caring about some of these databases. Anyway, then there are deprecated extensions that will be removed like mysql and ereg.

But this proposal, which has already been voted, was about to decide which ones would be no longer supported. There are votes for each of them, and most of the proposed extensions to be removed were accepted. Let me go faster here.

OK, below, I think mcrypt. The IMAP extension was not accepted to be removed because I think lots of people are still relying on them, so it would be bad. The same for mcrypt, and mcrypt... for those that may not be reminded about it... it's an extension that allows you to use cryptography libraries for different purposes.

And then, the others, they were also accepted. This is the final vote that happened. Actually, the deadline is today.

Arturs Sosins: No, that was last month.

Manuel Lemos: Sorry, sorry. You're right. The deadline was one month ago.

OK, with this, we can conclude is that despite there is people that have certain valid concerns about keeping those unmaintained extensions that rely on unmaintained libraries like imap and mcrypt, they were not voted to be removed. But I think the discussions will go on.

And this ties to the next topic, which is precisely the discussion about mcrypt. It is considered abandonware because the original developer is no longer working on it. So people are still considering either probably to take the library and maintain it inside the PHP project or provide wrappers around other libraries that implement the same functionalities, but the other libraries would be still maintained.

They have been mentioning about OpenSSL. Although, OpenSSL is a very different library, I think the work to develop a wrapper around it may not be trivial and requires a qualified developer to do it.

I don't know, Arturs, do you use, in your projects, any of these libraries like mcrypt and imap?

Arturs Sosins: I'm just starting thinking about it. You mean about old SAPIs or specific ones that you're asking?

Manuel Lemos: No, no. I mean the extensions mcrypt and imap.

Arturs Sosins: Well, probably, I know what are the softwares that are using it, including I think PHPMyAdmin uses it.

Manuel Lemos: Oh, yeah.

Arturs Sosins: It may be optional, but there is something using... I think it uses it, right? So that's what probably bothers me most about removing it.

Manuel Lemos: Yeah. Also, I have some class libraries that uses mcrypt for cryptography purposes and, well, if it is dropped, obviously, it will break and people that are relying on those libraries either do not upgrade to PHP 7 or you'll have the functionality that depends on those libraries not being enabled and that causes a lot of problem.

This is always a problem for when you are about to consider to upgrading to a new major version. There will be lots of people that will not upgrade at least in the first moment because it will break many things.

I think it happened... I think, I do not think, I'm sure it happened when PHP 5 was released. It has broken lots of things. Sometimes, it was not really broken, just warnings that are being issued. I remember in the beginning, if you use vars that are public, it issue a warning.

The intention was to encourage developers to migrate, but developers do not want to see warnings and if their code is not broken, they do not want to fix it. Or at least, they would need their employers to justify the time spent on fixing their code.

Sometimes, employers do not have the budget because it's just fixing code that is working and they probably rather not upgrade to that. And that caused lots of delays in the adoption of PHP 5.

So I don't know if there is a plan to avoid those delays to motivate people to move on to upgrade to PHP 7, but in order to get...

Arturs Sosins: One way would be to still maintain mcrypt but introduce an alternative. So there would be a time where user could switch...

Manuel Lemos: Well, for now, it is not being removed because there is not enough votes to take it to another... take the measure of removing it from PHP. So for now...

Arturs Sosins: I see. If it is abandoned, then it's just delaying the inevitable.

Manuel Lemos: Yes. So well...

Arturs Sosins: Maybe we can start thinking about alternatives...

Manuel Lemos: For now, it still have a few months, so they may decide to do one of the two things that I mentioned, which is to take the library and maintain it, or replace it with some alternative. I don't know which one is more difficult.

Probably, implementing a wrapper is difficult. On the other hand, maintaining the existing library requires somebody that really understands all the code there, all the kludges.

Well, I don't know, probably it's not that much work, maybe could be just a matter of dealing with eventual security reports and fix them, fix any issues. Well, let's see.

Okay, moving on with other concerns about the features that may break in the future. There is another discussion, which is about actually a variable that I was not aware because I never used it. There is a variable called $http_response_header which contains information, when you use stream wrappers to, for instance, use file access functions to retrieve Web pages over HTTP using for instance file hook or file or some other function, you can use this variable to access the response headers of the server.

I never used this, and probably I don't know if I would have a need for this, but there is a discussion here to remove this variable and use some other function.

And the same goes to another variable which is $php_errormsg. That is a variable that contains the last error of an operation that failed. For instance, you try to open a file that does not exist, that $php_errormsg will contain the error message regarding that failure to open the file. So, but for that function, there is already a function called get_last_message, but for this one, there is no function.

Well, anyway, the idea is to remove these variables, so legacy software that relies on these variables will break if it is not maintained. So there is not yet another challenge to people that are considering to upgrade to PHP 7 when it is released.

Arturs, did you use any of these variables in your programs?

Arturs Sosins: No. Even if I'm using HTTP as a client, I use an extension or cURL or something like that. I think that even if it's implemented it would be easy to implement to fix the setting of the variable with the provided function.

Manuel Lemos: Well, could be an idea, but still it is some concern for people that want to upgrade and rely on these things that are being discontinued.

Moving on with yet another feature that is being removed, actually it was already proposed and it was approved, which is the PHP 4 style of constructors, are those constructors that usually you have a function in the class with the same name of the class, so that becomes the constructor.

Arturs Sosins: Java style.

Manuel Lemos: Yeah. And then, later, they start using the __construct method. Now, they think it is not nice to keep both type of constructors, so it's time to remove them. This is really not an important feature, actually a removal of the feature, but it will upset people that have lots of codes that for some reason uses PHP 4 constructors. Probably it was started when they were using PHP 4, and since it worked in PHP 5, they never bothered to change the constructors.

So once again, this is yet another feature that is removed. It was not really important for anything, I think, but just a matter of style. We don't have two types of constructors to not confuse people or something.

Arturs Sosins: I think, actually, the proposal, it says that it will emit E_DEPRECATED in PHP 7 and will be removed in PHP 8.

Manuel Lemos: Right, right. Yes. Still, even issue warnings and notices is a bit scary for people that want to test if their application work in PHP 7. They see all these warnings and shy away from upgrading.

Arturs Sosins: I'm a kind of new, young developer and when I started with PHP, it already had the 5 version, version 5. So basically, when I see stuff like that, I'm always like really, you could use it? You could name a constructor as a class? I didn't know.

Manuel Lemos: Well, this is going to affect older code. Probably older than ten years, but I think even after PHP 5 was released, lots of people continue to use the PHP 4 constructors.

I did not find the article, but there was somebody that has written an article, that he was very upset with this proposal because it will not add anything but will only bother people to update code that is not broken again.

Arturs Sosins: If you look from the point of view of the core team maintaining PHP, it is just another case to check, for each constructor isn't defined like PHP 5 or PHP 4 and stuff like that.

It's a huge baggage. Even when we were talking about removing dead SAPIs, I notice one interesting comment about SAPI continuity, "No mortal remains of the corresponding server could be found on the internet". So it's supporting such an old Web server that it doesn't exist anywhere.

Manuel Lemos: Yeah, that is true.

Arturs Sosins: It tells all about the baggage that PHP was taking from each version to version, which...

Manuel Lemos: And that goes a long way, because PHP tried to embraced all sorts of extensions and Web servers. PHP prevailed and those Web servers didn't.

Enable opcache by default in PHP 7? (21:34)

Manuel Lemos: OK, next topic is about not something to be removed but rather to be enabled. Actually, this is a proposal to enable the op cache extension that was introduced in PHP 5.5.

This extension is having a built-in cache extension that will make PHP code load and start much faster. That was something that PHP always had since PHP 4 days, but they were third parties. So since they were not distributed by default with PHP, there was no solution for those, for instance, Web hosting companies that would install the extensions from the distribution, Linux distribution that they have.

So with this proposal, the idea is to have it finally enabled in PHP 7 because when it was introduced in PHP 5.5, it was not enabled by default. So it was a matter of enabling it.

I think it was a good idea. I just don't know why it took it so long because people that will benchmark PHP will consider the default configuration, and the default configuration did not have an opcode cache, so I think this is finally a good idea, at least the way I see it.

Arturs, in your environment, did you use any opcode extensions?

Arturs Sosins: Usually, I have a test server which is a shared hosting. There are lots of predefined settings that I can really change. So I think they should be enabled because servers usually want to conserve as much resources as they want, but I didn't check.

But, yeah, well, the proposal makes sense to enable it by default. I think it was introduced and it does not provide the downsides, then why not?

Manuel Lemos: Yeah, well, my concern with this was that I think they were concerned that when enabling the extension in the past that probably would cause some bugs to be exposed and probably not work. I think, if I remember correctly, that's why they did not had it enabled from the past. But now, it's more than time to have it enabled by default.

Arturs Sosins: It's stable now?

Manuel Lemos: Yeah, it should be more than stable after so many, well, years because this is the Zend opcode extension. They have been developing it for many years, although they have to maintain it on its release. So I think now, there is no such concern, not probably having it enabled to cause any problems.

So, it's good news. Well, for now, it is just being discussed. I did not see an RFC for this. Anyway, I think they are going to move on with it.

Caching PHP opcode Read from Streams (25:20)

Manuel Lemos: So moving on to the next topic is one that is probably not so trivial, but there is a proposal here. It is not new, it's from January, but somebody asking the PHP Internals.

I think it was Cesar Rodas that actually asked if you load some PHP code from... using a stream wrapper like for instance Phar or even HTTP... although that's not really something that advise, loading code from remote servers... the question was more about whether the opcode cache would cache the code loaded from those streams handlers like it happens when the code is loaded from files.

So it seems that it is not enabled so far for all stream wrappers. The idea is to have a function in the stream wrapper to determine if it could be cached or not.

So this is the proposal here. The proposal is not new, but now that Cesar asked it in the PHP internals list, I don't know if they are going to actually move on with voting this proposal. But I think it is interesting, although for most developers, probably not something to be concerned.

Arturs Sosins: I love the format of the proposal. Basically, the guy who proposed it, Francois Laupretre, he already created the pull request in GitHub with all the needed modifications including phar and plain files, is_cacheable() handler and also tests. Basically, it is like, "Here I propose this. I implemented it, just get commit..."

So we'll see if things like this pass through or not.

Manuel Lemos: Yeah. Well, I think that's because it is not really a new thing. We have already been two months after the proposal submitted some discussion. I really don't remember this proposal. Maybe I skipped by then, but now that Cesar Rodas mentioned something about stream wrappers and opcode caching, I got back to it. So let's see if this gets voted and approved.

PHP Parser Extension API (28:01)

Manuel Lemos: The next topic is about a new feature of the PHP Engine which is it the Abstract Syntax Tree, which is a result of a step of compilation. Let me share the screen here.

The proposal now... since now we have an intermediate step which generates an Abstract Syntax Tree, the idea is to have an API to access that tree. I'm not sure if you can manipulate the tree to implement eventual optimizations, but the idea is to have...

I see here two classes, and one for the PHP parser engine and other for PHP parser node. So I guess the engine is what parses the code, and the node is what results from the parsing of the Abstract Syntax Tree.

I'm not fully sure about the details of this, but I think the idea is if not now, it's probably to provide some way to optimize the code further. Well, I don't know.

Arturs Sosins: I think most probably use cases would be one for the parsers and two for quality insurance like implementing PHP lint or something like that.

Manuel Lemos: Yeah. Well, I think this probably is interesting, but I do not have any application for this in my mind. So this is a proposal from Nikita Popov. I think he was the person that introduced the Abstract Syntax Tree step in the PHP engine for PHP 7. I think the applications can be interesting but I'm not the qualified person to comment about them.

Zend Discloses their Open Source JIT Engine (30:14)

Manuel Lemos: OK, moving on with the next topic is news about Zend development that they have been working, shall I say secretly? I don't know.

Arturs Sosins: I think everybody knew that they are working on it, but they don't know... when and where and what.

Manuel Lemos: Yeah, at least suspected.

Arturs Sosins: Yeah.

Manuel Lemos: So this is the JIT engine that Zend has been working on. JIT means just-in-time. In this case, just-in-time compilation, which means that the code, at least in theory, the code would be compiled to native machine code right before the first execution of that code. Let's say we have a class with a function, when that function is called the first time it is called, the code will be compiled to native...

Arturs Sosins: And that make things programmable.

Manuel Lemos: Yeah, and optimized and so on. So last year, there was a big discussion because with PHPNG development, that later became what we know as the base of PHP 7. There was a big discussion because Dmitry Stogov of Zend announced that he was working on the eventuality of having a JIT engine in PHP and...

Arturs Sosins: It would mean then Zend JIT engine is ZIT.

Manuel Lemos: Yeah. It's not ZIT. It's JIT.

[Laughter]

Manuel Lemos: Well, as I was saying, he mentioned that he was working on tests to introduce JIT engine, to evaluate it if it would be worth the gains of an eventual optimization of the code. He started also working on other things that are not exactly the JIT engine. It turned out that they provided great enhancement.

So what he did is to propose that, what he called PHPNG, what we know today is the base of PHP 7. But many months later... I think it was September... September is the date of the, I think, first full commit in this GitHub repository where Zend posted their JIT engine.

So only now that they have announced it publicly to share with the community what their results are. He said that for now, he's not planning to invest effort in development of this JIT engine because PHP 7 is taking all his time. But that they have decided to share it and just say "Consider it available for academic purposes only at this point."

So for now, it's just to say, "We have a JIT engine here, we have some results." Nothing is said that it would be eventually included in PHP 7 or PHP 8 or whatever.

Arturs Sosins: It's probably disabled by default.

Manuel Lemos: Oh, exactly, like the opcode engine.

Now, I think the fact is that Facebook Hack, also bit on top of HHVM, the HipHop Virtual Machine, also features a JIT engine. So my guess is, this is somehow to become on par with the HHVM performance enhancements.

But there are already been some discussions. Several people that are very interested on this JIT engine, and they say that it does not always pay to compile the code to native code because the benefits are not good enough, not at all sufficient to justify it.

So for now, this is just an announcement of their JIT engine being made available. We don't know if there will be great developments about this in the future. We have to wait and see. I guess they are testing the community, see how they react, because I think there are several people also working on JIT engines, and I guess Zend is being careful to not upset them.

I don't know, that's a guess. That's an opinion. It's not a fact. That's just the way I'm guessing it now. I don't know, Arturs, what do you think about this?

Arturs Sosins: Well, the interesting part that they were quite quiet about it, and then they released it as an open source. I skimmed through the code and there are lots of parts like based on the list, the generation of incorrect code or something like that and command details. So yeah, it's really a work in progress, and it's probably to show the community like you said and get some feedback from them, then. You need a reaction.

Manuel Lemos: Yeah. Also, as it was mentioned in the past, the initial idea is to eventually port LLVM JIT engine to what then was called PHPNG, but then it ended up becoming what we know is the base of PHP 7.

OK, let's wait and see what comes out of this.

How to Check if an OAuth Token is Valid? (36:29)

Manuel Lemos: Moving on with the next topic, this time just to mention an article that I just released about PHP package, the PHP OAuth client, which is very popular because it is used to call APIs using authorization tokens, tokens that user provides to access the API.

There was a case that the class was not handling very well, which is when you want to check if the user already authorized the token, but if the user did not authorize, do not redirect the user to the authorization page. It just show for instance some link to tell user, "Oh, click here if you want to allow to access the API."

Because often, this class is used to login in certain sites using an account... for instance, Facebook or some other site, Google, or some other site.

This is just to comment about a recent enhancement to make this class just show about them instead of redirecting the user directly to the page, and also provide some other means to determine if a token that was retrieved in the past is still valid or not.

This class is able to renew expired tokens automatically, if there is a way to renew expired tokens. For instance, Facebook does not allow renewing expired tokens. You need to call the user again and ask him to go again to the authorization page, so you can get a new refreshed token.

But there are some APIs, for instance, Google that allows you to refresh expired tokens automatically. So this class already does that. And if a token is no longer valid because it was revoked by, for instance, the user changed the password in Facebook or something like that, and they revoked the tokens, there is no standard way to check if the token is revoked. So the only way you know it was revoked is calling the API and if it fails, it's probably because the token became involved for some reason.

And this is just for those that are interested in calling APIs. I don't know Arturs if you had applications that call APIs that use OAuth. I don't know if you have any other comment to add.

Arturs Sosins: Well, Facebook probably is the most popular one to which I have. But as you describe the problem, that really shows, I think, the down sides of the OAuth protocol. But on the other hand, there is no better alternative for now.

Manuel Lemos: Sorry?

Arturs Sosins: But on the other hand, there is no better alternative for now from the OAuth.

Manuel Lemos: Yeah, that's an issue. So for people that want to call OAuth APIs and for some reason, they need to deal with invalid tokens, they need to have their applications ready to deal with these cases.

JavaScript Innovation Award Winners of December 2014 (40:05)

Manuel Lemos: Well, anyway, we're moving on to a final section on which we comment about the Innovation Award nominees and winners, starting with the Innovation Award of JSClasses. So we're starting with the nominees of December. They were voted in January, so in February, the results come out, so now we can comment.

Arturs, which package would you like to comment?

Arturs Sosins: Let me share the screen first. It should be shared, right?

OK, so the one I wanted to comment is the package that is called Observer Pattern, which was developed by Chi Hoang from France. What this package does, it manages the list of observers that observe some changes in another object.

When I view the first example then, it did not make any sense to me. I don't know if you see anything, but basically those are some internal classes that they use. But when I run the example, it actually made quite sense.

It generates the list of observers that observe the changes in time class and get updated when it updates. So basically, that's the example of how it runs.

I don't know why there are some internal classes that does it, but you have to draw basically the main classes, the list that handles all the observers.

OK, so Chi Hoang got also one year server license IP to country for this package.

Manuel Lemos: That's good. On my behalf, I would like to comment on another package, which is UniDOM.js from Joseph, from the United States. He developed a package that provides an abstraction to access DOM elements. But, usually, the existing APIs, even in the browser too, to get DOM elements, they use the exact names of the classes or identifiers.

So this package provides a different alternative that allows to use regular expressions. So if you want to match elements that start with some name, you can put a regular expression and search for it in that way.

Arturs Sosins: This was a query selector, only with regular expressions.

Manuel Lemos: Exactly. That's a different alternative and for that, he was nominated. He did not pick a prize actually, because I tried to contact him, and so far he did not return. So Joseph, if you are listening to this, please contact back so you can reclaim your prize.

JavaScript Innovation Award Championship Rankings (43:24)

Manuel Lemos: So now, let's talk about the Innovation Award rankings. This time, we are already in 2015. Although we did not talk yet about the nominees of 2015, we can talk already about the rankings.

But we only had one nominee in January. It was a low month. So far, there is not much more to say than to say that Andras Toth is leading because nobody else participated in January. For that, Hungary is leading also in the ranking by countries.

So that's all we have to say about this ranking for this month.

PHP Innovation Award Winners of December 2014 (44:18)

Manuel Lemos: Let's move on with the Innovation Award of PHP Classes. In December, there were like ten nominees. They were nominated in December, then in January there was the vote, and in February, the results come out. So let's comment about these packages.

Arturs, which ones would you like to start?

Arturs Sosins: So the first one I wanted to comment is a class named PHP SSH Shell Script Generator, developed by Nadir Latif from Pakistan. Basically what this class does, it takes SSH commands from a file and generates like shells script that could be executed on multiple remote servers, remote computers.

Basically, you can create one PHP script to control multiple remote servers, update and restore them with this class. It's pretty cool, and probably that's why it also won the Innovation Award.

Nadir got one subscription to the PDF edition of the PHP Architect magazine.

The second one I wanted to comment on is the class that is called PHP DropBox Backup Uploader, developed by Ettore Moretti from Italy.

Well, we all need to manage backups. Some of us saving them on the same server, some of them uploading it to others. Some of them emailing them. And this class, what it provides is the option to save your backups to your DropBox Folder which syncs with your computer. I think that's an awesome option to do that.

Ettore got one downloadable e-book of choice by O'Reilly for this class.

Manuel Lemos: Well, on my behalf, I also would like to comment on a few classes. Let me share the screen here. The first one that I would like to comment is this one from Andre Liechti. I'm not sure if I'm pronouncing his name right. He's from Switzerland, and it is called Pure PHP Yubicloud authentication.

What it does is to check one time passwords on multiple servers. This is not a trivial matter, but it's related with security and one time passwords are used to share tokens that can only be used once.

They allow avoiding replay attacks, like for instance you pass the password and somebody stole that password, but since it can only be used once, it will not work more than the first time.

YubiKeys, I suppose, this is a product that generates one time passwords, and it can check them with cloud servers.

So for this, Andre picked one downloadable copy of PhpED Professional.

The next package that I wanted to comment is this one from Jacob Fogg, PHP Google Custom Search API, which is basically a response to a recommended package request.

Several people, actually a developer posted a request for package that could call this API of Google, which is basically a programmatic way to perform searches in a way that Google allows it. Because there are people that are scraping the search results of Google by crawling their search pages, but that is not acceptable by Google. Sometimes they block the IPs and so on, so the right way to use the Google Search is to use this API, and Jacob was nominated for that.

He picked one copy of VS.PHP, which is an extension for Visual Studio to work more well-integrated with PHP. So congratulations to Jacob.

PHP Innovation Award Championship Rankings (49:13)

Manuel Lemos: Now, finally, we are talking about the ranking of the Innovation Awards. Since we are already considering the nominees of January, we don't have many news to talk about. It's just to say that mostly, the ranking by author is practically the same ranking as the packages that were nominated.

So it was lead by Raskin Veniamin from Russia, and followed by Rafael Rodriguez that had two packages being nominated. And for that, he already got eight points for far.

There are several others here with less points. We're not going to comment on all of them, just move on to the Innovation Award Championship by country, which is lead so far by Russia because it's the country of the leader, Raskin Veniamin, then followed by Cuba with eight points, which are the same points of Rafael Rodriguez from Cuba, as I mentioned. Then, the rest are particularly the same positions of the other winners.

So I hope starting next months, when we have winners of different months scoring in this ranking, let's see how these ranking evolves.

Conclusion (50:56)

Manuel Lemos: Practically, we have ended this Hangout without my image, unfortunately, but we still have the image of Arturs. I would like to thank you, Arturs, again for coming.

On my behalf, that is all for now. Bye.

Arturs Sosins: Bye.

[Music]