Thursday, May 22, 2014

Why your browser should never actually directly download anything.

One of the reasons that application programming is so difficult is that the application is only provided very low level operating system calls to do most tasks.  This means that every application must reinvent the wheel when they do common, every day tasks that nearly every application does.  If you download 20 browsers you just downloaded 20 ways to cache files, 20 ways to handle bookmarks, 20 ways to download files, 20 ways to read and present a limited set of file formats and on and on.

There needs to be an application layer between the application and the operating system. The application should have no direct contact with the operating system.  Everything it does should be mediated by this middle layer.  

For instance, let's say you are writing a browser.  You have a text box for someone to type a Uniform Resource Locator (URL), and you have a button that you press to execute that query. In current browsers you would have to parse the URL, see if you know how to handle all the parts, and then make the network calls needed to get the requested file from the server.  You would have to assemble all the packets and parse the data all yourself.  If you got an image file, you would have to have a library to support that image format. If there is a caching system you would have to handle all that as well.  When the response comes back  you have to parse that as well, and then display it.  Often there will be multiple additional requests to complete.  Eventually the page will be done and displayed to the user.

A better way would be to just pass the request down untouched to an application layer that handles those requests, then handle the error, or pass the proper return value to a presentation element.  This can be a plug-able system where components can be updated and configured, independent of the browser.  The files returned to the system will be of specified formats.  These formats will also be plug-able and configurable and new media types can be added easily at the application layer.  These files will be properly parsed and verified by the application layer and handed back to the application to be handed right off the to the display portion of the browser application.

You remember how IE on Windows couldn't handle PNG files for like a decade?  And how they still don't handle SVG files? Well, with this new way of handling application building that kind of limitation will be a thing of the past. On this hypothetical system there will be just one way of handling a file format, and that one way will be heavily tested.  Any new flaws will be added to the test, and then fixed, and the tests all ran again to make sure the fix didn't break anything.  No values in a format will be believed without verification.  

There will be a single caching system for downloaded files and anything that wants cached files will share the cache.  The caching system will also act as a file down loader for other apps.    The same thing for bookmarks, and playing videos, and displaying images.

But here is where things will get interesting, instead doing it just one way, you should be able to install new modules that handle downloads and configure your system to use the new improved download manager that would handle file downloads better not just for a single browser, but for every file download on the system, every browser, every file manager.

The same thing should happen for every file format: images, video, audio, and media containers.  This means that the same media player and embedded media players will be expandable for decades just by adding new small format objects that are small and very limited in operation.  Their functionality can be severely limited by the system to only acting on streams of data.

These small files can be independently tested and such a system can be made much more secure than today's huge all in one applications.  Any updates needed to a format can be done quickly and easily and no reboot needed.  Because of the plug-able format handling it will be easy to integration test the complete system.  

This means that the browser itself would be much simpler, and just request support from the application layer/OS  to handle file downloads, presentation, and all file formats.  This means that browsers will also become very easy to write and test.   This also means that finally the browser features will fuzz into every application on a system, and make writing any sort of application easier.  Imagine downloading the latest web browser for a system, and it is only 100K of code.   Imagine a file manager that is only 10K. It would be possible to completely test such small applications.

So, having a real application layer that handles 90% of a typical applications behavior, in a plug-able way would make everything smaller, more easily testable/secure, and up-gradable in ways that today's applications are not.  

No comments:

Post a Comment