Browsers (3)
Hi folks,
After the very short history of browsers we have presented you in the past 2 “episodes”, today we are going to give you some light tech insights, as promised. Just so you can better understand why a plain modern browser is all you need to use DocuVieware-based web applications, at anytime, from anywhere.
But we need to tell you a word or two about browser plugins first.
When Netscape Navigator browser was first released, it allowed users to view only plain text, hyperlinks and images.
If another file format was to be encountered, the browser would download it and users would open it separately, with the appropriate application able to handle it.
Noticing this fact along with the intuition that the web might soon become universal, some visionaries at Adobe Systems including John Warnock (the CEO), contacted Netscape. They wanted to discuss the idea of a common approach to possibly make Netscape’s browser render Adobe’s document format (the PDF).
To illustrate the concept, 2 programmers at Adobe (Allan Padgett and Eswar Priyadarshan) had developed a proof-of-concept application which was presented in a live demo to the 2 CEOs: Jim Clark of Netscape and John Warnock of Adobe.
The demo was a big success: whenever the browser dealt with a link to a PDF file, it downloaded the PDF and automatically opened it inside its own window, amazingly handling both HTML and PDF formats.
The excited Jim Clark then asked who exactly from Netscape had helped with the browser-side coding.
The shocking answer was that… well… no one from Netscape was actually involved, it’s just Allan Padgett had made a bit of… uh… err…. well…, reverse-engineering on the browser.
But to a minimal extent only, so after the “no-offence-meant-none-taken” moments, both parties agreed that the concept should be properly implemented and released asap.
Apparently, Clark’s initial point of view was that Acrobat Reader’s entire code should be incorporated into Netscape Navigator’s code.
But merging 2 different applications into a single, monobloc application would have implied lots of subsequent issues and costs, for both sides.
So Allan Padgett insisted on his original approach of 2 different applications, each one developed and maintained by its owner, while a minimal common effort would focus just on the ‘contact points’ of the 2 apps.
Reason prevailed, his approach was adopted and this is how the browser-plugins era commenced.
Later on, Netscape provided APIs not only for Adobe’s PDF but for other file formats as well, while Adobe made plugins not just for Netscape Navigator but for all other important browsers that appeared afterwards.
That being said, perhaps now it’s easier to understand what a browser plugin is: it’s a piece of external code designed to be plugged-in to that browser.
This separate and externaly maintained piece of code is specialized in performing tasks that the browser alone cannot natively accomplish.
The browsers does what it’s primarily supposed to do: interpret HTML, CSS or JavaScript.
That is, it builds a webpage (and renders it to the user) based on the specs (or instructions) found in the HTML/CSS/Javascript source codes of the webpage.
So whenever it encounters a file format it cannot (because it’s not supposed to) handle, it checks if the correspondent specialized plug-in is also installed (or ‘added-on’ to it, hence the “add-on” word, synonym to “plug-in”).
If yes, then the browser simply assigns a visual area work-space to be the exclusive playground for the plugin/add-on and steps back.
From that moment on, what happens in that playground is the job of the plugin.
For example, a PDF plugin will render PDF files, Adobe Flash or Microsoft Silverlight plugins will render the video content they’re associated with, and so on.
If the browser determines that a required plugin is not installed it will inform the user about that and ask him to download and install the plugin if he wants to be able to view the content concerned.
Quite easy to do: various plugins are available for all kind of browsers running on all kind of Operating Systems.
In a nutshell: they are ubiquitous.
Unfortunately, in IT ubiquity/universality is the strongest magnet for the evil-intended.
The inherent security flaws have to be patched continously (when and if discovered… ) hence the frequent updates requirement.
Install other software besides the browser, shake with fear if thinking what might be happening to your computer when that software runs… nothing really funny about all this, isn’t it?
Enters DocuVieware.
Want to view or handle a PDF file?
No problem, just open your browser and carry on! No need for plugins or any other extra software or piece of code to be installed.
“But you just said that browser’s job is to interpret HTML/CSS/JavaScript/ … “, you’re going to say.
Yes, exactly!
When getting a PDF page generated by DocuVieware, the browser will render it to you as if it was open with best native Adobe software (even a little better, but let us remain modest…) by just doing what browsers are supposed to do: interpret HTML/CSS/JavaScript.
DocuVieware provides you all (and many more) functionalities for PDF viewing and handling without you needing to install/run/maintain anything else on your computer.
And because a modern browser is all you need, it doesn’t matter its brand, nor the Operating System it runs on, nor the device you are using (computer, tablet, smartphone, smart TV, you name it).
For those of you wondering why we’ve said ” modern browser”: the browser needs to be HTML5-compliant (which all modern browsers are) because DocuVieware sends to your browser all PDF information encoded as HTML5.
Voila!
Well folks, it’s time for us to end this article but maybe it’s a good time for you to see for yourself how DocuVieware performs. We have a dedicated website for interactive, live demos of DocuVieware and you’re all invited to go check it out!
Bye for now and see you next time!
Bogdan
Tags: