JavaScript: PDF Project

[Adobe PDF icon, courtesy Wikipedia]

Abstract:
Printing, fonts, and font rendering was standardized on the PostScript language. This grew into PDF, where individual pages would be rendered. Change continues to press on, with Adobe buying Frame Technologies, Oracle buying Sun Microsystems, and now Mozilla Foundation is moving web browsers like FireFox to render PDF natively via JavaScript.

[PostScript to bit map font, courtesy xaraxone]

History:
PostScript
PostScript language was born in 1976 by John Warnock. The first laser printers used it in Xerox PARC in between 1975-1976. Adobe was founded in 1982, Warnock a co-founder, and Steve jobs visited around 1984, and encouraged them to use PostScript to drive laerprinters. PostScript and Laser Printers merged, and the Apple LaserWriter was released in 1985.


[Adobe FrameMaker logo, courtesy Wikipedia]

Desktop Publishing:
Adobe, with desktop publishing packages (like FrameMaker, from Frame Technologies, later purchased by Adobe) creating the UNIX Workstation market. Quark's Xpress created the desktop Publishing Market, predominately under Apple systems. PostScript was embedded into the OS layer for displays on workstation vendors such as Sun Microsystems (NeWS) and NeXT (Display Postscript) and even a subset on PC's such as the Apple Macintosh (QuickDraw.)

[QuarkXpress Logo, courtesy Wikipedia]

Internet Publishing:
PDF was later created by Adobe, to allow the display of a page, instead of a document, allowing for better performance on long document rendering/printing, so multiple processors could work on multiple pages simultaneously.  This was at the beginning of documentation becoming electronic, instead of being paper driven. This was at the beginning of The Internet, when HTML was considered weak, but the potential was considered great.

[ISO Logo, courtesy wikipedia]

PDF:
PDF was created by Adobe in 1993. PDF became an open standard in 1998. The standard was published by the International Organization for Standardization as ISO 32000-1:2008. The Apple Macintosh was the first system to render PDF's natively at the OS layer. Only the newest PDF's require an OS plug-in. PDF viewing came natively to iOS devices like the iPhone, iPod Touch, iPad, and iPad Mini. Mozilla started moving towards native PDF rendering, making plug-ins unnecessary for all but the newest PDF formats.

[Mozilla Logo]

Mozilla:
Netscape:
Netscape Communications created in 1994 the first commercially viable web browser, web server, open secure transaction layer (HTTP encrypted over SSL, aka HTTPS) , client & server side scripting (originally termed LiveScript, later called JavaScript) - which is recognized as integral parts of The Internet today. All of this operated over an existing TCP/IP network.

In 1998, Netscape spun-off Mozilla, to create an open sourced network browser and other Internet tools, and many of it's commercial assets were consumed by Sun Microsystems.

PDF.js:
Mozilla launched the PDF.js project in 2011. The PDF.js project technology was recently released in Mozilla's FireFox browser. An example of the JavaScript based PDF viewer can be tried by anyone with an HTML5 compliant browser. This has been released in FireFox 19.0 Beta 1.

[Mozilla JavaScript rendering of PDF, courtesy Mozilla] 

Mozilla's FutureReleases blog discusses the new budding feature. It may be interesting to see JavaScript leveraged on the server side, with this library, to perform dynamic PDF content creation. 

Conclusions:
The Internet, a TCP/IP suite of applications, traffic protocols, documents, and media - which make up what is commonly called "the internet" today. Two decade old technology (HTML & JavaScript) seems powerful enough to now consume three decade old technology (PDF.) JavaScript will probably continue to grow ubiquitous, including servers side applications.

JavaScript Tab: Update!

JavaScript Developments

Another platform is available for Server Side JavaScript, when managed service providers require cross-platform capabilities. Vert.X framework looks quite interesting.


Vert.X - Server Side Cross-Platform JavaScript
[html] Vert.X - Effortless asynchronous application development for the modern web and enterprise
[html] Vert.X Documentation
[html] Vert.X Manual
[html] Vert.X Modules Manual
[html] Vert.X JavaScript API Manual

NodeJS: History of a Great Technology

NodeJS: History of a Great Technology

[2010-06-09] - Why Google V8 is not suitable for Servers (Russian)
[2010-07-09] - Nodes and Jetties
[2010-07-10] - Scaling NodeJS to Multiple Cores
[2011-01-03] - Gartner: Joyent in IAAS Magic Quadrant (NodeJS mentioned)
[2011-01-23] - Quick Benchmark: Java vs NodeJS
[2011-01-30] - Java AIO (NIO.2) vs NodeJS
[2011-01-31] - Node.js Interview: 4 Questions with Creator Ryan Dahl
[2011-02-05] - NodeJS: To V8 or Not to V8
[2011-02-05] - On Bruno’s Concern About the Current Coupling of node.js and V8
[2011-02-06] - Answering Jason on V8 governance and impact to NodeJS
[2011-03-08] - Yahoo code contributed to V8Monkey
[2011-04-11] - Mozilla progresses with JavaScript server project
[2011-04-14] - About That Hybrid "V8Monkey" Engine
[2011-04-19] - NodeJS on V8Monkey with Segmentation Faults
[2011-04-23] - News roundup: ... V8Monkey and SpiderNode ...
[2011-05-05] - Mozilla's NodeConf Presentation
[2011-05-19] - SpiderNode at NodeConf 2011
[2011-06-07] - Spidernode: 'let', 'yield' and array comprehensions in Node.js
[2011-09-10] - Hacker News - NodeJS: To V8 or Not to V8
[2011-09-11] - Ahead with Node.JS and Google V8

Java: JavaScript Object Notation (JSON) Coming!

Java: JavaScript Object Notation (JSON) Coming!

Abstract:
Variables and structures are normally held in various internal formats on different systems. Normally, this format is incompatible between programming paradigms. JavaScript Object Notation is one such notation, which has found popularity in the transfer of data as lighter-weight mechanism in comparison to XML. Java will soon be including native JSON support.

JSR 353: JavaTM API for JSON Processing
Java Specification Requests 353 was filed and accepted by the Java Community Process Program. It was summarized as:

The Java API for JSON Processing (JSON-P) JSR
will develop a Java API to process (for e.g.
parse, generate, transform and query) JSON.

A more complete description was also included:

JSON(JavaScript Object Notation) is a lightweight
data-interchange format. Many popular web services
use JSON format for invoking and returning the data.
Currently Java applications use different implementation
libraries to produce/consume JSON from the web services.
Hence, there is a need to standardize a Java API for JSON
so that applications that use JSON need not bundle the
implementation libraries but use the API. Applications
will be smaller in size and portable.

Network Management Implications
Many Network Management platforms have been using Java as their back-end engine, in order to stay compatible with the greatest number of data center infrastructures possible. For some mobile platforms, such as the iPad and iPhone, Java based front-ends are not adequately supported. This is driving many vendors to move towards JavaScript based front-ends, requiring other vendors to provide JSON parsing modules. The inclusion of JSON will reduce the reliance upon other JAR files and make JSON a full-fledged peer in the data-interchange arena for Java for Network Management platforms.

JavaScript Tab Update

JavaScript Tab Update

Abstract:
JavaScript, formerly known as LiveScript, standardized as ECMAScript, is a language originally used on both client and server web platforms. Through unfortunate historical vendor interactions, server side usage of JavaScript became less common. With the advent of JavaScript engines, which can be decoupled from the client browser, JavaScript became usable on the server side for independent projects.

History:
Netscape Communications brought to the market some of the first widespread adopted web client http browsers and web servers. One of Netscape's key technologies was called LiveScript - a client and server side technology to bring automation and communication to the browser and server suite. With the advent of Sun Microsystems cross-platform Java language, Java quickly became a hit, and LiveScript was rebranded JavaScript. Microsoft soon released their own web client & server platform, but only included a somewhat compatible client side JavaScript, creating a proprietary language on the server-side, leaving JavaScript to become less common on the server. Nations quickly figured out that Microsoft's half-baked implementation was a bad for the world and standardization soon occurred through ECMAScript. Sun's Java, with it's cross-platform capability, quickly became the language of choice on the server while JavaScript became the language of choice on the client. The battle for the fastest web browsers created teams of developers building JavaScript Engines, which could be decoupled from the Web Client. With the advent of decoupled JavaScript engines, developers started the movement back to server side JavaScript. NodeJS is a recent server side JavaScript non-blocking framework. NodeJS is based upon Google V8 engine, which unfortunately only works on a subset of known servers architectures and operating systems.

Resources:
The following are recent resource changes to the JavaScript tab on the Network Management blog.

NodeJS Specific Developments
[html] Server side JavaScript Engine: Node.JS
[html] Community Support for NodeJS
[html] Internal Developers List for NodeJS
[html] X11 Client Implementation under NodeJS
[html] X11 "nwm" window manager
[html] XCB directly rendered by node-canvas
[html] Google V8 JavaScript Engine

JavaScript Engines
[html] Mozilla SpiderMonkey (Various platforms)
[html] Mozilla Tamarin (Various platforms)
[html] Mozilla Rhino (Java based JavaScript engine)
[html] Google V8 JavaScript Engine (Intel, ARM)
[html] Mozilla JaegerMonkey
[html] Apple WebKit Nitro (SquirrelFish Extreme)
[html] Opera Presto

NodeJS: Non-Blocking Server Side Javascript

NodeJS: Non-Blocking Server Side Javascript

Abstract:
Multi-process models, in software like Apache web server, helps to add concurrency, to scale up. Similarly, multiple processors and later cores, adds concurrency in a hardware medium. Multiple threads sharing a process at the software layer assists in scaling higher while reducing the penalty of context switches. Multiple threads at a hardware layer also helps mitigate the penalty of memory accesses away. To continue to scale at the application layer, the migration to asynchronous programming allows for simple scaling, but programming language infrastructure had traditionally been negligent in facilitating the scaling easily. NodeJS, modeled using JavaScript, is a new framework to facilitate event driven server side programming where massive scale is required.

A Little History: X, Netscape, Navigator, LiveScript, LiveWire, JavaScript
One of the most ubiquitous frameworks which moved from synchronous to asynchronous was the X Windows system. This windowing system, produced by x.org, is indigenous on nearly every UNIX and Linux system. The next great user interface move was the web browser, to serve (through HTTP protocol) static content (HTML) with images, which became popular from Netscape through their Navigator browser. In an attempt to convert static pages to dynamic pages of data, LiveScript was create on the Netscape Navigator client and server side (as LiveWire.) LiveScript, renamed to JavaScript, leverages an event driven architecture in an application browser and web server, like X Windows was before it.

June 2009 Demo of NodeJS
Ryan Dahl, the creator of NodeJS, works at Joyent. In this early video, he presents his creation of Server Side Java Script programming framework, which is nearly all event driven.

Slides from the 2009 JSConf
These are the PDF slides from the 2009 JavaScript Conference, 2009 November 8.

Slides from the 2010 JSConf
These are the PDF slides from the 2010 JavaScript Conference, 2010 April 14

Video from the May 2010 Yahoo Talk
An introduction video to NodeJS presented at Yahoo on 2010 May 5.

Network Management Connection
Network Management becomes difficult when scaling to manage tens of thousands of devices and millions of managed virtual objects. The necessity to move to light transports like ICMP and UDP, was well understood, and could easily be made asynchronous. NodeJS would make a fine framework to model future network management infrastructure in, once it is stable.