diff --git a/1_Desktop/02_JavaScript/aptana_error.jpg b/1_Desktop/02_JavaScript/aptana_error.jpg new file mode 100644 index 00000000..33872799 Binary files /dev/null and b/1_Desktop/02_JavaScript/aptana_error.jpg differ diff --git a/1_Desktop/02_JavaScript/ch2_advancedjs.asc b/1_Desktop/02_JavaScript/ch2_advancedjs.asc index f2be296e..f17eff6e 100644 --- a/1_Desktop/02_JavaScript/ch2_advancedjs.asc +++ b/1_Desktop/02_JavaScript/ch2_advancedjs.asc @@ -186,7 +186,7 @@ TIP: You can also use +console.info()+, +console.debug()+, and +console.error()+ Now comes the chicken or the egg dilemma. What should we explain first - functions or objects? Understanding of objects is needed for some of the function code samples and visa versa. We'll start with simple function use cases, but will be switching to objects as needed. -Many of the readers can have experience with object-oriented languages like Java or C#, where classes can include _methods_ implementing required functionality. Then these methods can be invoked with or without instantiation of the objects. If a JavaScript object includes functions they are also called _methods_. But JavaScript functions don't have to belong to an object. You can just declare a function and invoke it. Just like this: +Many of the readers can have experience with object-oriented languages like Java or C#, where classes can include _methods_ implementing required functionality. Then these methods can be invoked with or without instantiation of the objects. If a JavaScript object includes functions they are called _methods_. But JavaScript functions don't have to belong to an object. You can just declare a function and invoke it. Just like this: [source,javascript] ---- @@ -369,15 +369,20 @@ var p = { lastName: "Roberts", p.makeAppointment(); ---- +===== ss +===== Creating Objects Based on Other Objects + + + === JavaScript and HTML Elements After learning all these facts and techniques about the language you might be eager to see "the real use of JavaScript" – manipulating HTML elements of Web pages, which most of the people use JavaScript for. This is correct, at least today. In this section we'll be doing exactly this – applying JavaScript code to HTML elements. -First let's consider the operations we need to be able to perform inside the Web page: +First let's consider the operations your application needs to be able to perform inside the Web page: * Programmatically finding the required element by id, type, or a CSS class. * Changing styles of the elements (show, hide, apply fonts and colors et al.) @@ -385,8 +390,7 @@ First let's consider the operations we need to be able to perform inside the Web * Dynamically adding or removing HTML elements from the page or changing their contents * Communicating with the server side, e.g. form submission or making AJAX requests for some data from the server -You’ll need to understand how to perform these operations from JavaScript. Even if you’ll be using one of the popular frameworks, you'll be performing the same operations applying the syntax prescribed -by your framework of choice. So let's get started. +You need to understand how to perform these operations from JavaScript. Even if you’ll be using one of the popular frameworks, you'll be performing the same operations applying the syntax prescribed by your framework of choice. So let's get started. === Styling Web Pages with CSS diff --git a/1_Desktop/08_Websockets/Chapter_8_Replacing_HTTP_With_WebSockets.asc b/1_Desktop/08_Websockets/Chapter_8_Replacing_HTTP_With_WebSockets.asc index 5f68a484..091db9a7 100644 --- a/1_Desktop/08_Websockets/Chapter_8_Replacing_HTTP_With_WebSockets.asc +++ b/1_Desktop/08_Websockets/Chapter_8_Replacing_HTTP_With_WebSockets.asc @@ -1,161 +1,164 @@ -== Replacing HTTP with WebSockets +== Chapter 8. Replacing HTTP with WebSockets + + + [quote, http://ietf.org/mail-archive/web/hybi/current/msg00784.html ] ____ Shaving off hundreds of bytes of HTTP overhead and reducing the latency from 150ms to 50 ms makes WebSocket worthwhile considering for any application. ____ -This chapter starts with introducing of existing "legacy" options for creating interactive Web applications. After that we're going to introduce Server-Sent Events and WebSockets, which are included in HTML5 specification. +This chapter starts with introducing of existing "legacy" options for creating interactive Web applications. After that we're going to introduce Server-Sent Events (SSE) and WebSockets, which are included in HTML5 specification. -We're going to implements the fund-raising event monitoring functionality and interactive auction for Save Sick Child application using Websockets and Server-Sent Events. Using the monitoring tool we'll show the performance bandwidth usage benefits that WebSockets protocol brings to the Web. +We're going to implement monitoring of the fund-raising events and an interactive auction for our Save Sick Child application using Websockets and Server-Sent Events. We'll use Wireshark, a network monitoring tool, to see benefits of using WebSockets protocol. -Will use http://java.net/projects/tyrus[Project «Tyrus»] with http://dlc.sun.com.edgesuite.net/glassfish/4.0/promoted/[latest Glassfish builds] for the server side Websocket implementation. +All server-side functionality supporting this chapter is written in Java, using the http://java.net/projects/tyrus[Project «Tyrus»] with http://dlc.sun.com.edgesuite.net/glassfish/4.0/promoted/[latest Glassfish builds]. If you don't know Java, just treat this server side setup as a service that supports WebSockets. For Java developers interested in diving into the server-side, we'll provide the source code and brief comments as a part of the code samples that come with this book. -Show the server-side data push with Server-Sent Events and Websockets. Compare each other. -Look at http://socket.io/[Socket.IO] library. Compare the data throughput with the HTTP data push demonstrated in Chapter 4. +TODO: Show the server-side data push with Server-Sent Events and WebSockets. Compare them. +Do a brief overview of the http://socket.io/[Socket.IO] library. Comparing sending data using WebSockets data throughput with the HTTP data push will be demonstrated in Chapter 4. -=== Legacy Web Options for Realtime Applications +=== Near Realtime Applications With HTTP -HTTP protocol is the lingua franca of today's Web applications, where client-server communications are based on request-response paradigm. On the low level, Web browsers make TCP/IP connection for each and every HTTP request-response session. And every time when we need to send data to server and get response back the browser re-establish the TCP/IP connection. So to implement interactiveness in your application currently, there are 3 basic options that developer has to use today to satisfy the real-time client-server communication requirements. Basically, that options provide hacks on top of half-duplex HTTP protocol to simulate real-time behaviour. Lets discuss each of them. +The HTTP protocol is the lingua franca of today's Web applications, where client-server communications are based on the request-response paradigm. On the low level, Web browsers establish a TCP/IP connection for each HTTP request-response session. Every time when the browser needs to send data to server and get response back the browser re-establish the TCP/IP connection. So to implement interactiveness in your application currently, there are 3 basic options that developer has to use today to satisfy the real-time client-server communication requirements. Basically, that options provide hacks on top of half-duplex HTTP protocol to simulate real-time behavior. Lets discuss each of them. -==== Polling aka Short Polling ==== +==== Short Polling ==== -With polling, your client code sends request to the server every X seconds The response is «empty» if there is no update. Refer to Figure 8-1 -Good illustration of this approach is you child seating on back seat of your car and asking "Are we where?" every minute. And you replying back with empty response "No, we're not". There is no actual interesting payload for your kid but he still receiving some "metadata". Same with short polling what uses HTTP response with verbose headers to send empty payload. +With _short polling_, your client code sends requests to the server every N seconds. The response is «empty» if there is no update as illustrated in Figure 8-1. Visualize a child seating on back seat of your car and asking, "Are we where?" every minute. And you're politely replying "Not just yet" - compare it to a empty server response. There is no valuable payload for this kid, but she's still receiving some "metadata". HTTP polling does the same thing that generates verbose HTTP response headers sending empty payload. Let alone destructing the driver (think the server) from performing other responsibilities. -_TBD short polling illustration_ +_TODO polling illustration_ Figure 8-1 Short polling ==== Long Polling ==== -Long polling is similar to short polling: client sends request to server and instead of sending empty response (as in case with short polling), server not committing the response until information is available. When information gets available or after certain timeout server sends response and closes connection. And this process is repeated. On the contrary of short polling, long polling response is never empty. -From HTTP specification perspective this "hack" is legit: long polling server behaviour indistinguishable from «slow» server. That is why this technique also referred as "Hanging GET". Essentially, long polling is not server-push, but good emulation of it in situations where server push not available. +_Long polling_ starts similarly to short polling: the client sends HTTP request to server. But in this case instead of sending an empty response (as in case with short polling), server waits till the data for the client becomes available. If the requested information is not available after the specified timeout, the server server sends an empty response to the client and closes the connection. + +We'll give you one more analogy to compare short and long polling. Imagine a party at the top floor of a building equipped with a smart elevator that goes up every minute and opens the door just in case if one of the guests wants to go down to smoke a cigarette. If no one enters the elevator, it goes to the ground level and in 60 seconds goes up again. This is the short polling scenario. But if this elevator would go up, and waited till someone would actually decided to go down, then we could call it a long polling mode. + +From HTTP specification perspective this "hack" is legit: long polling server behavior indistinguishable from «slow» server. That is why this technique also referred as "Hanging GET". If you see an online auction that automatically modifies the prices as people bid on the item it looks as if the server pushes the data to you. But most likely, this functionality was implemented using long polling, which is not a real server-side data push, but its emulation. -_TBD long polling illustration_ +_TODO long polling illustration_ Figure 8-2 Long polling +TODO Compare pros and cons of long vs short polling + ==== HTTP Streaming ==== -Response to client never -Client sends the request, server wait for events and streams +multipart/chunked+ response, and then wait for the events. The response is continually appended by server, usually with `