Will it ever Matter if PHP Sucks? - Lately in PHP podcast episode 23 - PHP Classes blog

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)

PHP 5.4.1 and 5.3.11 releases and Apache 2.4 support (2:29)

The polemic of the pure PHP scripts proposal (5:57)

Case sensitive PHP function names proposal (12:26)

Proposal to skip optional arguments in PHP function calls (16:52)

"PHP Sucks but it still doesn't matter" (19:23)

Making the Web Faster with HTTP 2.0 and consequences for PHP developers (33:26)

Latest JavaScript Objects published in the JSClasses site (50:17)

PHP Programming Innovation Award of February 2012 (56:41)

Conclusion (1:03:44)

Manuel Lemos: Hello, welcome to the Lately in PHP podcast, this is episode 23, and this time we're starting something new, an experimental thing which is basically to record and actually transmit the podcast recording live to whoever may be attending.

Pprobably this is not the best day to record, only Ernani came here to the podcast.  Hello, Ernani, how are you doing?

Ernani Joppert: Hello, Manuel, I'm doing great, lots of things to talk about, I'm glad to be here and see if this goes as a different experience.

Manuel Lemos: Yes, it certainly will go, actually we already recorded the...

Ernani Joppert: The JS Classes, right?

Manuel Lemos: Right, the first edition of JS Classes...

Ernani Joppert: Oh, I see some little elephants there.

Manuel Lemos: Right.  Basically these are the well-known PHP mascots, actually there is a big one and a small one, but actually as I mentioned previously, there will be a new one which will look like the original PHP mascot.

Ernani Joppert: From PHP Classes.

Manuel Lemos: Right.  PHP Classes mascot, I'm trying to show it in the screen, this is a prototype, this is not the final version of the new mascot. In the end it will look like exactly as you see in the PHP Classes site.

This is just a test, they are still iterating, and hopefully it will look much closer to the logo used in the PHP Classes site which is basically a creation of Ifat Amit, a lady, that created the current design, the current theme of the PHP Classes site.

PHP 5.4.1 and 5.3.11 releases and Apache 2.4 support (2:29)

Manuel Lemos: And, anyway, we are actually moving on to the actual podcast, and today we have several topics, several interesting topics to talk about starting from the just released PHP 5.4.1 that was released yesterday, today is already the 27th, and yesterday it was released both PHP 5.4.1 and the PHP 5.3.11.

Well, there is not much to say about these revisions of PHP, probably the greatest new thing that was introduced is the support for Apache 2.4 which was not previously working, the build was not working with that Apache version, but now it seems to be working, I have not tried it yet, but I actually intend to upgrade PHP 5.3 to this revision 11, and mainly because it contains a security vulnerability fix done by Stefan Hesser in a way that magic quotes are handled.

I do not use magic codes anywhere, but since it seems to be a security vulnerability it's always good to upgrade.

Ernani, are you already using PHP 5.4, are you planning to, what is your plan?

Ernani Joppert: Yes, I'm planning to do an upgrade, I'm still with 5.3-something, can't recall.

Manuel Lemos: Well, personally I'm not planning any upgrade anytime sooner than when I really need it, and at least for me PHP 5.4 does not provide anything that I really need, like traits.

It's interesting but I do not have a great interest in them, and PHP as it is is already good enough for me, I mean prior to PHP 5.4, but other people may want to upgrade. For instance, the use of the built-in web server which is mainly meant for development environment, it's interesting but you don't need to upgrade your version in the server.

Ernani Joppert: Yeah, eventually it can also represent a problem because when you're doing development you should develop within the host environment that you will plan to deploy, so if you use Apache then you have to test it with Apache, but I understand for small testings it's a valid improvement for the solution.

Manuel Lemos: Yes, I'm sure several people were expecting PHP 5.4 to be a release to use the new features.

Ernani Joppert: Oh, yeah.

Manuel Lemos: We don't know yet if it had great adoption, it will probably only have adoption on environments in which the developer somehow controls besides the version that is available, and we don't really need it much, but people that need it will take advantage of those features and will appreciate it.

Anyway, we talked a lot about PHP 5.4 features in past episodes, so there's no need to go through the features again.

The polemic of the pure PHP scripts proposal (5:57)

Manuel Lemos: We are going now to move on to something else that has been happening in the PHP world, actually this month was sort of intense.  I'm not sure if it was intense in terms of importance, but there was a topic that is discussed..

Ernani Joppert: A little heat.

Manuel Lemos: Well, a little bit, it's just a way of saying it was intensively.

Ernani Joppert: No, I mean a little heat on the topic, like on the discussion.

Manuel Lemos: Yeah.  And the topic that I'm referring to is basically the proposal to have a sort of variant of PHP source file that does not allow those PHP start and end tags, so the regular PHP scripts are basically mean to be some HTML or something else, and with PHP embedded on it using those PHP start/end tags.

So the proposal is to sort of, well, not exactly abolish because they still want to support the current form of PHP source files.

Ernani Joppert: It seems that this is an RFC proposal right, and they are trying to separate the mixed PHP with HTML and pure PHP scripts as far as could understand in order to facilitate some specifics on frameworks related code as well as naming conventions, etcetera.

Manuel Lemos: Yeah, well, actually that's probably the ironic part of the proposal because the proponents seem to want to stop people, or at least discourage people from mixing HTML templates inside the PHP or vice versa, whatever you want to see it.

And what they propose it to have a new type of PHP source file that only includes PHP code, and the current way of embedding HTML or some other kind of output in the middle of PHP would be disallowed.

And I think the ironic part is that many frameworks, many MVC frameworks they propose the use of PHP files, actually it would be HTML templates with PHP embedded on them.

And this somehow means that they still want to have that forever, embedded PHP code in the middle of HTML or whatever is the output from that.  And anyway, we are just talking about this because the discussion was quite intense.

Ernani Joppert: Oh, yeah.  And what would you think about having this adopted, I mean are you up to it or what's your preference?

Manuel Lemos: Well, personally I do not care because even if I was in favor of implementing a specific alteration in PHP engine to support those different types of PHP source code I probably would not care, but for those that want to use those PHP only code they can do it now, the only thing is that they still have to put those PHP start and end marks in their source files, so all this discussion because they do not want to put those marks.

Ernani Joppert: I mean I'm sure that there are some other important things to care about, right?

Manuel Lemos: Well, right, but regarding this proposal the discussion was so intense, I probably missed maybe some important arguments in favor of it, but the best argument in favor of it was that they sort of are concerned that sometimes use PHP start and end marks, and for an accident you enter an additional line break and that may break PHP code like, for instance, triggering the issue of the content type headers.

And, well, okay I understand that is a concern, it happens, it actually happened to me some time ago, but it doesn't happen to me every time, and I'm not sure if all this discussion is justified, it seems that somebody just started the idea and everybody also wanted to give their opinion.

There is not just one RFC, from what I counted there are at least three RFC's that basically propose the same, just a slight variants of the same idea.

I think because I really did not have much patience to go through all the proposals, but, well, for me it's like you said, I do not intend to use it, I'm not really concerned, I just wanted to mention it because there is this intense debate, and from what I could understand it did not yet end, and probably people will keep talking about it.

And it's just amazing how something that may not really be necessary to be part of PHP raises such a great discussion, actually a flame war, and, well anyway that's just my perspective, I don't know if you have a similar perspective.

Ernani Joppert: Yeah, I totally agree with you, I mean it should, those changes probably are useful for some people otherwise it wouldn't even be proposed, but yeah, normally changes within the PHP engine or the PHP core itself it's kind of problematic and it brings lots of ins and outs, and it's always a struggle in that sense.

Case sensitive PHP function names proposal (12:26)

Manuel Lemos: Yeah.  Well, anyway, there were also other proposals despite this proposal itself took a lot of discussion there were other proposals that did not get so much attention, but I think it will probably be worth mentioning.

There was one that was sort of proposing, or at least reviving an old topic, discussion whether PHP function names should be case-sensitive or be case-insensitive just like they are currently, and the main argument in favor of making it case-sensitive is if you use certain characters to be represented in Unicode, UTF8, the upper and lower-case version of those characters is just not a matter of changing one byte.

And for me I just wonder, well, is it really something normal to write PHP code using non-ASCII characters?  Ernani, I don't know if you use names in Portuguese in your code, but you don't, right?

Ernani Joppert: No, no, no, especially when there are special characters.  I try to keep everything English, sometimes you just don't care and you write some variables names in Portuguese, but I try to avoid it.

And normally what I do is I use the spell correction tool just to make sure that it can understand everything, and I do this such as a reports tool for the code when I'm looking into the code.  But, yes, I have never had the experience of having to write variables with special words or special characters.

Manuel Lemos: Yeah, well, for me this is a bit odd because, also despite my mother language is Portuguese which has some non-ASCII characters I never use them, actually I was not even sure if PHP supported non-ASCII characters in names, the functions.

Ernani Joppert: I don't think I've ever tried and never have used a special word or accents on a variable just to see if it works, I can't even tell.

Manuel Lemos: Yeah, well, I know that the original proposal of PHP 6 was meant to make this a common thing, if you wanted to write your code with variables and functions in Chinese you could, but, well it seems that the person that proposed this was concerned about these words in foreign languages that making the upper and lower to match names during the execution of PHP to see...

Ernani Joppert: Maybe they want to make the convention similar to what Java does with camel case script such as I guess Ruby as well requires that.

Manuel Lemos: From what I understood the idea is to avoid the overhead because if you want to see if a name is the same but with a different case you have to probably map all to lower case or all to upper case and compare the versions of the names.

And actually if you are using non-ASCII characters and you are using, for instance UTF8, some characters will be mapped to two bytes or maybe more in some idioms, some languages.

And I think the person in question wanted to avoid that overhead, but the problem is that it will cause major backwards incompatibilities, and this I don't know if that headache would be worth making all case-sensitive, and I think the main concern was to be performance.

Well, anyway, the discussion on this proposal practically died do I don't think it will go anywhere.

Ernani Joppert: Right.

Proposal to skip optional arguments in PHP function calls (16:52)

Manuel Lemos: Anyway, moving on, another proposal that will probably go on because it seems to be useful and does not cause any backwards incompatibilities in PHP, is the possibility to when you call a function that has optional arguments you can skip some of the arguments and specify the last ones.

This is an interesting feature of PHP which probably makes it more flexible than other languages that do not have this thing, which is the optional values in the parameters, because this allows, for instance, if you want to evolve your code and now you want a certain function to have a new parameter you can add that parameter and assume the defaults so old code that used to call the version with less arguments would still work.

And the idea of this proposal I think it was from Stas Malyshev, whom is one of the maintainers of PHP 5.4, although this proposal does not seem to be related, is the possibility if you have several optional arguments, parameters to a function, in the call you can skip some of the middle optional parameters and only specify one or more of the last parameters.

And I can see certain cases in which this would probably be interesting because it would allow you to change the default values on some of those key parameters.  And it seems the proposal got some acceptance and probably will be implemented in a future PHP release, well, we'll see. Personally I find it interesting.

Ernani, during your so-called day job you work more with Java, I suppose Java does not have optional parameters in functions, right?

Ernani Joppert: No, no, no, you have to specify them all.  But in ActionScript you can specify some fields with a predefined value such as null, and if it's not passed then it takes the default, but Java doesn't.

Manuel Lemos: Well, for me it's very interesting, and I think it's one of the advantages that is rarely discussed, which is the possibility of those optional parameters.

"PHP Sucks but it still doesn't matter" (19:23)

Manuel Lemos: Okay, but moving on with our podcast, we are going to talk a bit about yet another discussion against PHP, there is this article with the title "PHP, A fractal of a Bad Design", which goes through an extensive list of I would say inconsistencies or things that you can say that in PHP are a result of something that was not well designed in PHP as a language.

And I think this discussion that showed up a lot in many sites, I think in the HackerNews forums it was discussed a lot, and when I found this article basically it was a tweet by Jeff Atwood, one of the founders of the StackOverflow site, and he is well known by his alias @codinghorror, and he has a lot of articles related with programming for which he has a lot of followers.

And I found a tweet by him that basically says that "PHP sucks but it still doesn't matter". Well, he says it still doesn't matter because in 2008 he already wrote an article precisely with that title in which he was commenting that despite all the problems that PHP has, PHP is a very popular language no matter what.

So from what I understood basically he was saying that it's sort of pointless to complain about PHP because that does not affect PHP popularity. 

In my opinion PHP popularity came from the fact that it was a language created for creating web applications, and since the Web got very popular PHP also got very popular.

Other languages followed to provide better support for web programming, but they came out later. And other than that several killer PHP applications may be so popular that it's going to be impossible for any other language to defeat in the web field. I am thinking about, for instance, WordPress and others, other applications written in PHP that make PHP like a plague, you can't get rid of it.

And this is very interesting because although we PHP developers already know very well those deficiencies of PHP, we don't bother because we all got used to those deficiencies, so it doesn't matter for us if somebody claims with a well thought article with all the arguments against PHP because it won't change our minds, we work with PHP, we make money with PHP, and although we reckon that other languages are probably better designed, it will hardly make a difference for us.

And that was one point, another point is that all these articles that PHP sucks and PHP should be banned, or whatever are their intentions...

Ernani Joppert: Yeah, I guess this goes with the maturity level of the writer.

Manuel Lemos: Well, it's not just that, I think all these people that complain about PHP have an agenda to promote some other language.

Ernani Joppert: Yeah, oh, sure.  And it's sort of a maturity thing as well because you see some analogies that they compare Yoda with etcetera, and then you see the drill, but it's not just that Yoda is something immature, but I'm bringing the funny part here, which it's like in order to be somebody you have to be a Jedi, and this is not a Jedi thing, and then you see the drill, you see the whole dilemma about who came in first, the egg or the chicken, and they go around and then you don't see much of a well concise frustration about it.

I mean, okay, there are better languages, but if you have to do it with a small footprint and you don't have RAM enough within your server to host a website and you need to have a blogging system write off the hand, or you need a forum, I've seen lots of other Java community sites which use PHPBB as their bulletin board.

Manuel Lemos: Right.

Ernani Joppert: So the point is there is no point in complaining about specific language otherwise there wouldn't be different languages, it's like complaining because you don't like to speak English or you don't like to speak Portuguese, and you never speak anything else, but it's ugly, and it goes nowhere, it's another language, so if you need to communicate with a team that only speaks French you will have to learn French or they would have to understand your English.

Manuel Lemos: But, well, what I think is that those people that are complaining for some reason they had to face a job on which they are mandated by their bosses, or whoever, to use PHP and shut up, and that's probably annoying them so much.

Ernani Joppert: Oh, I see.  So they hope that writing these high-impact articles, well described with all the arguments against PHP, they hope that somebody sees the light and stops using PHP.

Manuel Lemos: Yeah, but it's like you working in Brazil and you don't like Portuguese-brazilian because you're from Portugal, and you complain because everybody here speaks Brazilian Portuguese, it doesn't make any sense, I mean you're in Brazil so you have to speak Brazilian Portuguese.

Ernani Joppert: Right.  In Rome you have to be Roman.

Manuel Lemos: Yeah.  And try to go to a certain country where they are very nationalistic about their rules, we all know that France has a very strict language rule, and it's very hard sometimes to get something out of them by just throwing out English because people are traditional, so they prefer to keep their patriotism.

Ernani Joppert: Well, in their country they are entitled to demand that everybody speaks their language, but if they are tolerant and if they are friendly they should somehow allow the fact is that not everybody knows French or had the opportunity to learn French.

Manuel Lemos: Yeah.  Although if you go to France you should somehow learn the basics.

Ernani Joppert:  But let's put it this way, you need customer service and you are in a different country, will you request for them to speak in English with you, okay, if it's a prime thing and you're paying for it then it makes sense to request that, but otherwise you have to speak their language, there's no point.

And this is where I feel it should be compared to, not a Java versus PHP versus Ruby versus Python, it goes nowhere.

Manuel Lemos: And another thing they also learn is that besides adapting to the fact that we all use a lot of PHP and sometimes you have no choice, and if your boss says that you have to use PHP either you use it or maybe you'll leave the company.

But other than that, PHP is the great Kool-Aid, actually I don't know if you are familiar, but for those that are not aware this is the PHP Kool-Aid, this is the PHP drink.

Ernani Joppert: Oh, yeah.  If you're thirsty enough you have to drink it, yeah.

Manuel Lemos: Yeah, well, now for those that are wondering this is sort of a souvenir that I got when I was a very long time ago in an international PHP conference in Germany in Frankfurt, and there is an expositor company, I think they're no longer operating.

Ernani Joppert: Have you taken a sip out of this drink?

Manuel Lemos: Me, no, no, I pretend to be drinking it but it has not every been opened, actually it's probably poison by now because it expired.

Ernani Joppert: It's kind of radioactive right now.

Manuel Lemos: I got this in 2001 and it was only valid for consumption until 2003.

Ernani Joppert:  Wow!  So it's like an energy drink which became a radioactive thing.

Manuel Lemos: Probably, I don't know, I will never try it.  Anyway, well this is just a joke for those that keep bitching against PHP, drink this PHP Kool-Aid and you'll be happy.

Ernani Joppert: Yeah.  And it would be nice to challenge them, you know, if you hate PHP so much you should try that drink.

Manuel Lemos: Adopt an elephant, guess how many languages have such a cute mascot as the elephant.

Ernani Joppert: Yeah, be animal friendly or we will call PETA on you.

Manuel Lemos: It's clearly... look at it and see that it's an elephant, for instance, Java, what is the Java mascot, I could not understand what kind of animal...

Ernani Joppert: It's sort of a penguin, The Duke, it's sort of a penguin, but the main logo is coffee, a coffee cup.

Manuel Lemos: Oh, yeah, because Java is a drink somewhere, right?

Ernani Joppert: Yeah, it's sort of a grain of coffee I guess, from Java island, I'm not sure about it.

Manuel Lemos: So it's not even a power drink like PHP.

Ernani Joppert: I'm sure it has caffeine though.

Manuel Lemos: All power drinks have caffeine.  And, well, cheers, more power to the PHP developers.

Ernani Joppert: Sure.

Manuel Lemos: Well, enough jokes, we respect every developer even being a diehards of other languages.

Actually personally I do not think of myself a PHP diehard, I think languages are just tools, and you should use an appropriate tool for each job, sometimes it's PHP but it may not be PHP, it may be JavaScript and Node.js or Java, whatever.

Ernani Joppert: You're also a very well known C programmer, I mean you know a lot of C programming, and you could write the ultra-fast modules for Apache and don't bitch about it if you have to.  But the point is you have to find the right tool, the right tool for the job.

Manuel Lemos: Life is too short.

Ernani Joppert: Yeah, sure, and the performance increase would make sense to have.

Manuel Lemos: Yeah, yeah.  Well, anyway, enough of this topic, I hope everybody gets the message, we are not campaigning for or against PHP or any other language.

Ernani Joppert: And if somebody starts complaining we will launch a motto of ‘okay, stop bitching about PHP and go write Assembly software then'.

Manuel Lemos: We will release a mob of elephants go after them.

Ernani Joppert: Yeah, go write Assembly and stop bitching about any language then.

Manuel Lemos: But then there will be people complaining now what kind of CPU, would that be CISC or RISC or would it be X86 or PowerPC.

Ernani Joppert: Write for everything, fork the code, I mean put whatever requirements you have to do within your code to support whichever processor you're working with.

Manuel Lemos: Well, by the way, did you know that I think it was Joel Spolski, or at least an employee of his company FogCreek, that developed a language named Wasabi, which is basically an abstraction of a language I think for web programming that in the end it generates either PHP or ASP code?

So I think he did that so he could address the market of customers that may prefer or not the Microsoft world, and PHP will run in both worlds, but if the Microsoft world customers prefer ASP or .NET, or whatever is that they prefer, they can use the same code and same language scope to get it translated to ASP or whatever.

And so that's the way they found to embrace all the world, or at least a great part of the world, with a single code base, it's a sort of a meta language.

Making the Web Faster with HTTP 2.0 and consequences for PHP developers (33:26)

Manuel Lemos: Well, anyway, moving on with our podcast, actually we were talking about performance, and just a few days ago it was released, well, I'm not sure if it is, it's not exactly RFC but more a list of proposals for what will become the HTTP 2 protocol.

As everybody knows, HTTP is the base of the Web, it's the protocol by which browser and servers communicate, but several researchers have found that it's time for it to have an upgrade.

Ernani Joppert: I've seen some blogs, just to break the ice here, that they specify HTTP as "Here This is The home Page".

Manuel Lemos: I have not seen that...

Ernani Joppert: Or here, this is the page.

Manuel Lemos: ...explained that way.

Ernani Joppert: Here, this is the page.  But the point is the protocol communication, right, and getting it improved based off of Google.  You're more familiar with that, the new things about SPDY and Google and the draft proposal.

Manuel Lemos: Well, I had a look at it briefly, actually by the time this podcast will be published, I hope it was already published, an article I'm working on to actually give an overview of what are the proposals, what is being thought to be the HTTP 2 version.

Ernani Joppert:  And one concern I had is why wouldn't they change it to HTTP 1.2. 

Manuel Lemos: Maybe they need to make it to look as something bigger.

Ernani Joppert: Or probably will go with Web 2.0 thing.

Manuel Lemos: Well, I don't know if that is what you had in mind, but HTTP 2 one of the concerns is that it should be backwards compatible, so browsers and servers that do not speak the version 2 of the protocol will still work and will still be able to talk with each other in HTTP 1 or 1.1, so HTTP 2 being backwards compatible it could be well be called HTTP 1.2, why not.

Well, I think the main idea is to give a perspective that this is a major upgrade, although it will be still backwards compatible, but from what I understood the idea is that the first connection to the server is to verify if it supports HTTP 2 protocol or not, if it doesn't support it will keep talking in HTTP 1.1 or 1.0 if that's the case, but if it is able to upgrade the protocol or the communications, it will be able to take advantage of the new way to operate.

And the new way to operate is somewhat different because first it will be what we already know about WebSockets, for those that are not really familiar with the idea of WebSockets it's basically a way to communicate with the server, and it will bidirectional.

Ernani Joppert: Yes, and probably it will focus also on mobile systems as well, right, because it's now the next big thing.

Manuel Lemos: Well, there are some concerns regarding mobile connections because if you send very large packets the communication may break down and it will make it much slower than it should be.

Ernani Joppert: And binary as well.

Manuel Lemos: Yeah.  But continuing what I was saying, one of the concepts that is being adopted for HTTP 2 is the WebSockets that allow bidirectional communication.

But another aspect is the sort of adoption of another protocol named SPDY, I think it should read it speedy, and it's basically a protocol from what I remember it was defined by Google, and it is already implemented in the Chrome browser, and also recently in the Firefox browser.

And several sites support it already, I think the Google search supports SPDY protocol, and it seems that the main reason why it's so fast, interactions between the browsers and servers are very fast.

One thing that it allows to work in a very usable way is those sort of instant searches that while you are typing your search terms you can already see the results page and it appears very fast, you notice that it's already there.

Anyway, Google implemented this protocol and they built it in Chrome, and as I said, Mozilla implemented it in Firefox in very recent releases.

And one good thing that Google provided for those that want to take advantage of this SPDY protocol is the actual implementation of Apache extension that will convert interactions between the server and the browser using, well, this Apache extension, and on the server side you continue to write your applications the same way, but you still have some benefits of the SPDY protocol.

Ernani Joppert: Just giving a glance here on the items I've seen they have proposals for one connection for per domain, which is kind of neat, it would represent like Facebook, let's put it this way, Facebook has several child applications within their server, so how redirects would be done.

And there's a lot of things to read about here as well as compression of context, which we already have within web services but it's not built into protocol.

Manuel Lemos: It's basically a single socket connection, that's why there is this WebSockets protocol.

Ernani Joppert: Yeah, I'm just naming some of those, I mean one connection per domain, fixed versus variable length, compression context, unidirectional streams, data compression, server push, some security considerations as well such as HTTP headers and SPDY headers, cross-protocol attacks, and server push implicit headers, so probably there will be some peculiarities when you're talking push notifications and stuff.

Manuel Lemos: From what I understood since it is all over one single socket connection, as opposed to what we have now, for instance, if you access a site it returns a web page, then the browser will have to fetch its CSS files and JavaScript files separately, and eventually those are done over different connections.

And the way this SPDY protocol seemed to work from what I read, I'm not sure if this is exactly, it will be a sort of multiplexing of data that is being transferred between the browser and the server.

For instance, if you request images and they are from the same domain you can request several images and they come from the server simultaneously in the same connection.

And this reminds of a protocol I have studied and implemented, actually a client recently, which is the one that is used by Git. You know Git version control system, that became very popular recently.

Since I had developed a class to support them, protocol to import packages from Git repositories, I had to study protocol and most of the data exchanges are done in binary, well, practically all the exchanges are done in binary, although they work on top of HTTP.

And with a single request you can do a Git clone which is basically retrieve all the information of the files and revisions and all the things, and it can do it with a single request, and that seems to be basically the idea that is being implemented with SPDY protocol.

But for what does this matter for people that develop PHP applications?  Well, as I said, to support this eventual evolution because the current HTTP version will work differently from the HTTP 2, there needs to be a sort of migration path, and Google is providing mod_SPDY, which is a module that will convert the request and responses between browsers and servers.

So you can continue to use your regular PHP applications, make the same assumptions they had that you received, the way that you generate responses that are sent to the browser, and this module will do the conversions.

So you don't have to concerned on changing your application, at least for now, to take advantage at least part of the benefits.

But for other benefits I think like the interactivity, the ability to communicate between the browser and server, I don't know if the way PHP works now would not have to be re-thought, this is still a matter of study, but I am sure there will be enough motivation because everything will be very much more interactive, the communications, the request and responses between browser and server will be much faster.

Ernani Joppert: And what do you think, do you think that this will be happening at the same pace as HTML 5, or do you think it will be promoted quicker, because most of HTML 5 are required the browsers to adopt them as well, right?

Manuel Lemos: Well, basically this is a protocol that is somewhat agnostic to the actual applications, it does not matter. The way data is transmitted between browsers and servers does not matter much to the browsers, because all the protocol it's not that complicated, but once it is implemented, which is the case already in Chrome and Firefox, everything will work.

I mean it's implemented the SPDY, and SPDY is one of the proposals for HTTP 2, the final HTTP 2 specification will be something that has to be agreed between proponents of several ideas, not necessarily it will be something compatible with SPDY.

Ernani Joppert: Right.  But do you think would it be compatible, I mean not compatible, but do you think it would be adopted by most of the browsers by the time HTML 5 is completed, or do you think it will be started to be implemented in the end of HTML 5 specification?

Manuel Lemos: Well, the problem is HTML 5 is not a single thing.  HTML 5, first it's not HTML that people are talking about, it's not the tags, it's basically the APIs, JavaScript API's, and part of the problem is that many of those API's the specification is not finished.  

Ernani Joppert: You have some specific renderers like WebKit, I mean Firefox has its own system of rendering graphics such as Chrome and Safari uses WebKit, I'm not sure what IE uses.  But the point is do you think that HTML5 specification would be benefitted by this new protocol?  I mean of course we alreay have WebSockets on HTTP 1.1, so that's the main idea here, do you think it would benefit?

Manuel Lemos: Well, I don't know because the things are independent, anyway, applications need to be adapted to take advantage of the new features, being either on the HTTP protocol or on the HTML 5 API's.

It's not automatic, you have to write specific code to take advantage of those features, at least part of the features like the possibility to interact between browsers and servers provided either by WebSockets or SPDY or whatever will call the HTTP.

Well, anyway, we have to wait and see, this is still a very recent topic.  Anyway, as I mentioned it's an article that I'm working on and it will hopefully be available in the first days of May, we are currently at the end of April so it's just a matter or waiting and see.

Anyway, by the time this podcast is being published I think that article is already live, it's just a matter of going there and reading more about the details.

Ernani Joppert: Yeah, I just hope that most of the libraries, I mean JavaScript libraries and server side libraries wouldn't have to be concerned about the big changes and if it would be able to let's say work on both HTTP 1.1, if the browser doesn't support it, the requesting browser HTTP 2 then if it would be transference to the PHP application or to the JavaScript application.

So this is where I am concerned about it because then it would see JavaScript you have to test browser functionality, and it's always a pain, so you would have to test protocol and it's always a pain and it's always adding complexity to an existing code, and that's where my drama comes on.

Manuel Lemos: Yeah.

Ernani Joppert:  And regarding the HTML 5 specification, I mean it could be that in order to be an HTML 5 compliant browser it would have to implement the HTTP 2.0 specification, I mean in the end they could vote for it, but I'm not sure if it will happen but I hope all those features...

Manuel Lemos: Those things are independent.

Ernani Joppert: Yeah.

Manuel Lemos: You can implement HTML 5 API's on top of HTTP 2 protocol, or HTTP 1 and vice versa.  Anyway, for those concerned about the PHP applications the current PHP applications will still work.

What you may consider in the future is to somehow take advantage of these features to implement something that will be more efficient because most of these new things in HTTP 2 are meant to achieve greater performance.

And just to close this topic, just a reminder that there was a class submitted by I think it was Nathan Brewer from the United States that implemented the server side implementation of the WebSockets protocol.

And it was all done in PHP. It creates a separate process for each connection, and PHP code would be called and from then on it would be a part of the PHP to take advantage of these WebSockets possibilities of interactivity.

Latest JavaScript Objects published in the JSClasses site (50:17)

Manuel Lemos: But, well anyway, let's move on with our podcast, we are reaching our end, and the next topic is one of the regular sections in which we comment about classes that have been published in the JS Classes site, and we're just going to comment on a few of those classes, there are not many object, JavaScript objects, published recently in the JS Classes site.

Let's take a look, there have been a couple of classes, actually one of them was written by me, this Smooth progress bar, which is basically a class that implements a progress bar that appears very smoothly on the screen,  updates its position very smoothly.

Ernani Joppert: And since you were the writer of it are you using any functionalities of WebKit or you're just using CSS 3?

Manuel Lemos: No, no, there's nothing fancy on it.  Basically what works this object does, when you update the position of a progress bar if the next step jumps to many positions in the progress bar the way it appears it is that the position of the progress bar will increase smoothly over time, it doesn't jump directly to the final position.

It's a nicer appearance of the progress bar, and since it's not so sudden the user can see what is happening very clearly, and hopefully this will be a nicer way of showing the progress to the users.

Ernani Joppert: And this can be used to upload files or to perform some server tasks, right?

Manuel Lemos: Yes, this is a generic JavaScript component, it can be used to show progress of any task that is going on on the server, eventually there could be some interaction with the server, but it's not the role of this object to perform, it just shows progress and updates the position smoothly.

Anyway, Ernani, do you want to comment on a class?

Ernani Joppert: Yes, the class that I will comment on was the other component that was submitted within this month, and the author is from Ghana, which I've never seen before within JS Classes as far as I can recall, and his age 25, his name is Archzilun Eshun-Davies, I seen that there are some particularities of speaking Davies or Davis, so I will try to be general here, and sorry if I mention it wrong.

Yes, but the object seems to be very flexible for AJAX requests, it's a common component, already everybody knows probably what AJAX means, if they don't it's a Asynchronous JavaScript and XML communication between the browser and a particular server.

And this falls back into the specific components within Internet Explorer, which is always a struggle to develop with because of the inconsistencies between API's, and it does fallback within ActiveX components within existing IE, so it tests for those functionalities.

And by using this library you can interact with AJAX and not care about browser incompatibilities, which is always an advantage if you're short on time or if you're not into looking into the specifics of each browser and you want to achieve a very nice result, and I feel that you should try to use this component, it's very nice.  The name of it is XHR.

Manuel Lemos: Right.  This is a very... the function, as you said, the function of this object is very simple, just send an AJAX requests and call some callback functions that you provide, and it will let you integrate your application with AJAX requests in a way that works in all browsers.

And despite it's very simple it's always good to have a contributor from Africa, in this from Ghana, because we don't have many and we like to always encourage everybody not just from Africa but from everywhere to keep sending objects.

This is JS Classes site like the PHP Classes site is a very global site, there are practically authors from all countries, and everybody is welcome.

And other than that, I would like to encourage every author, not just from the JS Classes site, but also PHP Classes site, to keep sending their components, and in this case Archzilon is also a contributor at PHP Classes site, and he is now participating also in the JS Classes site like many other authors, but everybody's welcome to send their components.

And we will always be talking about the most relevant components that they send to either site. And this is part of the reason why we are talking here about JS Classes site components that have been published as a form of encouragement to everybody to keep contributing.

PHP Programming Innovation Award of February 2012 (56:41)

Manuel Lemos: But now moving on to another regular section in which we comment about the latest components published in the PHP Classes site that have been nominated for the Innovation Award edition of January, actually February. And there were like six nominees, and this time which components would you like to mention, Ernani?

Ernani Joppert: Yes, I picked two, the first one which is untrivial to me, I've never seen it before, I wasn't even aware that Groupon had an API, and the name of the component is Groupon API as well, so a Groupon API client.

And basically what it does is it can retrieve the list of revisions, deals and individual deals details, and it can send HTTP requests to the Groupon Services API web server to perform operations on deals of Groupon.

And this is very nice for, let's put it this way, participating portals that share offers there, so they can have their own offers within their own system and use the Groupon API to publicize those.

So it's very nice, the contributor is Portuguese from Portugal, Fernando André, and I mean he's a Portuguese speaker but he's from Portugal, which is not trivial, I don't think I've seen much Portuguese contributors here, so this was funny to say.

And, Fernando André, congratulations, it's nice to see this coming forward, he has 29 years and probably has a bright future ahead, congratulations.

And the other component is related with image functionalities. I'm not sure if this component uses any particular library within PHP such as GD or something, but yeah.  

Manuel Lemos: It uses GD for the actual resizing not for reading or writing the GIF format.

Ernani Joppert: Oh, I see.  So, yes, it's a PHP GIF resizer, GIF Animation Resizer is the name of the class, the author is from Turkey, his name is Taha Paksu, sorry for the difficulty here.

Manuel Lemos: We always say it wrong, don't worry, I hope people will understand.

Ernani Joppert: He was nominee two times already and winner on one time, so congratulations again to be here.

This class resize animations in files of the GIF format, so if you have animated GIFs and you're concerned about them being resized within PHP you can see it's possible, I've never seen the requirements about it, but it's nice to see that it can be possible with PHP, so very good.

Manuel Lemos: Yes, there was one class that deals with reading and writing animated gif pictures, and that was submitted many years ago, I will have a hard time saying the name, someone name Lazlo, sorry, I would not be able to pronounce the name correctly even if I remember because it has many new letters to me.

And basically what it did is to read and write animated gif files. And for some reason there seems to have been a revival of GIF images, animated GIF images, because it's a way to send pictures to a site and make them appear animated. And there are many social networks that like to show these kinds of pictures, but they have to be in the right size, so that's why this class from Taha Paksu is very useful and I hope he continues to send more great classes like this.

On my part I also would like to mention a couple of classes that I thought would be interesting. One which is basically to somehow replicate the functionality provided by the PayPal site which is to send emails with payment requests to a given address.

I think PayPal provides this feature but you have to login the PayPal site and send the request, but in this case Mubashir Ali from Pakistan created a class that does it all in PHP so you do not rely on the PayPal site.

You can have a script that uses class to send a payment request to user by email, so kudos for Mubashir for providing this class.  

And another somehow unusual class that I would like to mention is this cDBbackup, also again by Archizilon Eshun-Davies. As I mentioned he is also a contributor of the PHP Classes site.

And he was nominated for sending what apparently seemed to be yet another class to generate MySQL database backups, but in this case what it does is somewhat different, instead of generating the actual backup files, and usually those backup files are SQL statements, basically a list of SQL statements that will be saved to a file so they can restart a database by executing those statements.

But this class does something a little different which is to generate an actual PHP script that generates the actual backup. So instead of doing the live backup immediately it generates a PHP script and you can use that script elsewhere and it just does that, that you need to take a backup of certain database tables, and it's a different approach to take a backup of MySQL database.

Conclusion (1:03:44)

Manuel Lemos: Well, basically this concludes our podcast, I think it was...

Ernani Joppert: No, videocast, right?

Manuel Lemos: Right.  Well, I think it's all a podcast.

Ernani Joppert: Or hangcast.

Manuel Lemos: Well, I don't know.

Ernani Joppert: I'm not hanging, but anyhow.

Manuel Lemos: What we will call these kinds of recordings that have live transmission is hangouts on air. It's quite a long time for something that we are adding doing now in video which is a podcast.

Well I think we will continue to call it a podcast, and for me I think it was a great experience, now not only can you see our beautiful face,s you can also see elephants.

Ernani Joppert: A Commodore Amiga 4000 on top of it.  I see your PS3 on your left side.

Manuel Lemos: That's a more recent generation, it's my son, he's in the other room playing frantically Playstation games.  You can also see the PHP power drink somewhat.

Ernani Joppert: I think I have some gadgets on top of my... I have very old keyboard from Apple, I have an RC controller and a Chinese media backup thing.  Yeah, I mean it's technology in the end.

Manuel Lemos: That is the advantage of doing it all in video.

Ernani Joppert: And by the way, I guess goes to the future of things, we'll all be conferencing eventually and working from home, and I see this technology as a very positive thing.

I use... when I need to learn something I use all those video references and screencasts all the time and it helps a lot, and eventually we can have some special screencasts here by sharing presentations and stuff, so it's very good to see those technologies coming forward.

Manuel Lemos: Yeah, and other than that, besides showing whatever gadgets we have at home, or where we are recording, I think it was great. I did not use it much in Lately in JavaScript podcast, but in this podcast I remembered I could use it to show the actual pages of the components that we are talking about, and that's far more interesting than showing our faces to the public.

And over time we will get used to doing that more often, show other things that maybe some code or something that are relevant to the topic we are showing.

And other than that, one thing that I wanted to mention,  I don't know if I am doing anything wrong but when I announced this podcast a few days ago, and other people can participate, everybody is invited to participate, up to ten people can participate in the actual recording, and many people can still watch the podcast recording live, but for some reason, or maybe that's not the way it's supposed to work, the invitations that I sent out in the Google+ are not reaching people.

I thought it would get to people by email but it doesn't seem to be the case.  I thought it would probably show in the notifications of Google+ but for some reason it did not go out, but now this first episode I hope everybody pays more attention and can participate.

I hope also I can announce it with more time in advance so people can schedule some time.  The only thing it will probably be hard to schedule the recording to a time during the day that would be more convenient for everybody in the different parts of the world to also attend, but those that can attend if they were not aware now you should be aware that it's possible to participate in the podcast.  I hope to see you all in the next episodes of the podcast.

Ernani, what were your thoughts about this different type of participation?

Ernani Joppert: Yeah, I really like it, and I had a souvenir to give to the users at the end of this podcast, but I'm not sure if I will be able to make it.

Manuel Lemos: Oh, it's a surprise?

Ernani Joppert: Yeah.  It's just a silly end thing, and I wanted to show by sharing my screen, let me just see if I can do it.

Manuel Lemos: Can you activate the screen sharing?

Ernani Joppert: Yeah, I'm trying to, now I'm having some problems here.  I'll leave it for the next episode so we can have more users included.

Manuel Lemos: I already have put my glasses on.

Ernani Joppert: Sometimes when I'm showing you small character things you have to be able to read it, I unfortunately don't have any papers to show you.

Manuel Lemos: Well, let's leave that surprise to the next episode.  

Ernani Joppert: Yeah, sorry.

Manuel Lemos: Maybe you can rehearse a bit so you can show it with more time.  Well, on my behalf that is all for now, it was a great pleasure to be on this podcast, and hopefully in the future editions more people can come and make this experience richer, so for me that's all for now.

Ernani Joppert: Yeah, thanks a lot guys, I really appreciate being here.

Manuel Lemos: Bye.

Ernani Joppert: Bye, bye.