With newer, modern hardware systems, it is likely that they will contain either multiple physical processors or a single physical processor with multiple cores. When writing applications with these systems as the target platform, it is often a good idea to utilize more than a single process within the application. Why is it that multiple processes make sense within a single application? One may be inclined to think of the concept of a process as being designated for a single running application, or a one-to-one cardinality if you will. On top of moving away from the comfortable idea of a single process for a single application that so many developers are used to, there is also the messy problem of inter-process communication. This particular problem isn't quite as bad as it is made out to be. We just need to use the appropriate abstractions on top of the inter-process communication functionality. Going back to the question of why it is a good idea in the first place, the chief benefit of using multiple processes within a single application is the performance gains. While the same application concurrency logic implemented using threads will offer better responsiveness, the multiprocessing approach offers an opportunity for true concurrency on systems with multiple processors.
The Firefox web browser is currently implementing a version of the browser which incorporates multiple processes rather than having the entire application run in a single process. As discussed above, this entry provides some rationale behind why the development team decided to implement this functionality. Aside from the inherent performance gains offered by systems with multiple processors, there is increased stability. The stability is increased because independent processes decouple the entire browser architecture. This helps provide a degree of isolation not available in a single process. The stability gains are especially apparent when considering the multiple tabs used to view disparate web pages. Security could potentially be improved as a side effect of the isolation provided by processes. Finally, not mentioned in the entry but equally relevant in design terms, the distribution of responsibilities within the web browser system becomes very clear. It sometimes takes a drastic move to improve this design principle such as moving entire pieces of code to a separate process.
In this entry, a demonstration of the browser running a separate process for the tab content shows a clear stability improvement. Even after killing the content process, the user interface process remains in tact.
Showing posts with label firefox. Show all posts
Showing posts with label firefox. Show all posts
Thursday, July 9, 2009
Thursday, February 19, 2009
Strange Gnome screenshot behaviour
I noticed some strange Gnome behaviour when attempting to take a screenshot. This only seems to happen in firefox. If I want to take a shot of an expanded menu on a form, Gnome wont let me. I assume that this has to do with the window focusing. It seems to me that this would be, well, not a common requirement but it is a failed use case nonetheless.
Tuesday, January 27, 2009
Friday, January 2, 2009
Is javascript ready for the desktop?
The web browser has come a long way since its' inception. The first basic requirements of the web browser were to retrieve and format hypertext. Now, you can pragmatically display content within the browser using javascript. Firefox offers another level of programmatic customization using XUL.
This is nothing new. The web browser and javascript have both been around for some time now. Also not new is the fact that the web browser runs on the desktop. So the question is javascript ready for the desktop seems a little obvious at first glance or perhaps even just plain wrong. Another form of the question might be can javascript applications replace the majority of existing desktop applications. To most developers, or desktop users for that matter, this question of javascript desktop readiness simply leads to endless other questions.
The most important of course being why bother. If we already have all these applications that run perfectly well (and fast) on the desktop, why replace them? I would argue that as of right now, there probably is no reason to replace desktop applications. However, I would also argue that the possibility and feasibility of replacing certain desktop applications is certainly worth thinking about.
The speed argument may be a show-stopper in many cases. Especially when the latency involved arises as a result of loading the code that is the application. If a javascript application is running on the desktop, the javascript code already exists on the desktop and therefore the latency involved in delivering the application is removed. What about the data involved in application? If the data is remote, the same latency is going to be involved regardless of the client using the data. In fact, the tricky part is when the data resides on the same desktop as the javascript application.
Trying to perform read and write operations on the desktop hard drive using javascript is hopeless. So how do we make the hard drive operations available within javascript? My solution would be to create a simple HTTP data server that runs on the desktop. This server would provide only what is required to manipulate the hard drive. The server would not host the application code or any static files for that matter. It is not needed since all the application resources are local. The only need for the server would be raw data access.
Here, a simple node depicting the desktop computer contains the server component and the browser component.
Now suppose this worked (I have not actually tried it), that would mean it is possible to write javascript applications for the desktop. What now? We need some rationale for doing so. On the development end, productivity levels increase when building GUIs using a combination of javascript+HTML+CSS. In my opinion, as a developer (I'm by no means a GUI designer), I find writng javascript much simpler then trying to use a traditional GUI kit such as Qt. Especially given that talented CSS designer can create exceptionally beautiful work using only CSS.
The work is also simplified with javascript toolkits such as dojo. The dojo toolkit provides a multitude of GUI widgets that are already themed quite nicely. I also find interesting the fact that these toolkits have come into existence. It goes to show that there is a real desire to use the web browser as a platform.
Where to start? What would be the first desktop application to re-write in javascript? How about a file browser? It should be a fairly simple application to write and would serve as a useful proof of concept. Text editor? There are some reasonably powerful editor widgets which provide half the implementation.
So, as a quick summation, there is no real pressing reason to develop desktop applications using javascript. However, for the future, it may be worth exploring now. Especially considering the recent major speed enhancements made to the Firefox web browser. Opera is another quality in which to use this future platform. Although IE sucks, its' market share is currently a reality.
This is nothing new. The web browser and javascript have both been around for some time now. Also not new is the fact that the web browser runs on the desktop. So the question is javascript ready for the desktop seems a little obvious at first glance or perhaps even just plain wrong. Another form of the question might be can javascript applications replace the majority of existing desktop applications. To most developers, or desktop users for that matter, this question of javascript desktop readiness simply leads to endless other questions.
The most important of course being why bother. If we already have all these applications that run perfectly well (and fast) on the desktop, why replace them? I would argue that as of right now, there probably is no reason to replace desktop applications. However, I would also argue that the possibility and feasibility of replacing certain desktop applications is certainly worth thinking about.
The speed argument may be a show-stopper in many cases. Especially when the latency involved arises as a result of loading the code that is the application. If a javascript application is running on the desktop, the javascript code already exists on the desktop and therefore the latency involved in delivering the application is removed. What about the data involved in application? If the data is remote, the same latency is going to be involved regardless of the client using the data. In fact, the tricky part is when the data resides on the same desktop as the javascript application.
Trying to perform read and write operations on the desktop hard drive using javascript is hopeless. So how do we make the hard drive operations available within javascript? My solution would be to create a simple HTTP data server that runs on the desktop. This server would provide only what is required to manipulate the hard drive. The server would not host the application code or any static files for that matter. It is not needed since all the application resources are local. The only need for the server would be raw data access.
Here, a simple node depicting the desktop computer contains the server component and the browser component.
Now suppose this worked (I have not actually tried it), that would mean it is possible to write javascript applications for the desktop. What now? We need some rationale for doing so. On the development end, productivity levels increase when building GUIs using a combination of javascript+HTML+CSS. In my opinion, as a developer (I'm by no means a GUI designer), I find writng javascript much simpler then trying to use a traditional GUI kit such as Qt. Especially given that talented CSS designer can create exceptionally beautiful work using only CSS.
The work is also simplified with javascript toolkits such as dojo. The dojo toolkit provides a multitude of GUI widgets that are already themed quite nicely. I also find interesting the fact that these toolkits have come into existence. It goes to show that there is a real desire to use the web browser as a platform.
Where to start? What would be the first desktop application to re-write in javascript? How about a file browser? It should be a fairly simple application to write and would serve as a useful proof of concept. Text editor? There are some reasonably powerful editor widgets which provide half the implementation.
So, as a quick summation, there is no real pressing reason to develop desktop applications using javascript. However, for the future, it may be worth exploring now. Especially considering the recent major speed enhancements made to the Firefox web browser. Opera is another quality in which to use this future platform. Although IE sucks, its' market share is currently a reality.
Subscribe to:
Posts
(
Atom
)