Women in Technology

Hear us Roar

  Rethinking the Linux Distribution
Subject:   requirements first (2)
Date:   2007-05-14 15:17:42
From:   georgebelotsky
Response to: requirements first (2)

There is no intrinsic reason for the browser to be so central, but there is a definite historical reason. In the end it is simply how things turned out.

At this point, Mozilla has invested a lot of effort into Firefox. Version 3.0 of the browser will have DOM storage and offline execution. This is a highly advanced FOSS project, with a lot of momentum. To match their significant technological achievement and market penetration would be a formidable task indeed.

The above reasons is why I suggest adding X Window manager features to Firefox, making it the central mashup point for both SaaS and local applications.
There is definitely a valid argument against putting too much in the browser, but what is the alternative? Maintain two separate desktop environments: the browser for SaaS, and a traditional X setup for local applications?

Note that currently, the X-based desktop is the unifying construct, and the browser just another application that runs on top of it. Firefox, however is not just an application -- it is on the verge of becoming a platform. So, I am proposing to better integrate these two key systems, by making Firefox act like an X window manager.

Of course, as you earlier pointed out, we do need to worry about many things, especially state management and the network protocol. HTML/HTTP is not the ideal solution. It should be possible, however, to solve these problems at higher protocol layers. This approach may not have the best architecture, but it avoids the monumental task of recreating Firefox's functionality elsewhere.

Given your Java background, JavaScript will certainly seem strange to you. It does have an object model, and perhaps even its own peculiar elegance. Still, JavaScript OO development is very different from Java OO development.

Since you prefer working in Java, maybe Google Web Kit (which automatically generates JavaScript from your Java code) is the right tool for you?


Full Threads Oldest First

Showing messages 1 through 2 of 2.

  • requirements first (2)
    2007-05-17 00:46:23  Kuros [View]

    You are right about the historical reason... In fact legacy is always a problem (not just in Webdevelopment) and so far no silver bullet for dealing with it. I also don't see a problem with using FF as a base, however you also have to deal with IE. Or are you assuming that FF will be the dominant browser? Again, I think DOM is really problematic, where it not for the necessity to use HTML, no GUI designer in their right mind would use DOM/HTML as a basis for GUI design. Bringing X-Windows into the Browser (what about IE?) is a great idea, if it means that I'd have a component hierarchy for GUI design (and also addressing the HTTP bottleneck). I think Sun had the right Idea with using Swing in the browser, but that project failed among other, because the JDK became too bloated, but I think a similar way is the way to go, instead of HTML. Perhaps using a layer of Javascript is sensible, sort of a javascript virtual machine, on top of which I'd use a more elegant (networked) language which also works on the serverside (I know that Javascript has also a server edition).
    • requirements first (2)
      2007-05-21 13:46:50  georgebelotsky [View]

      Support for IE (and other browsers, especially Safari) is certainly an important area to cover. Since the article's topic is the future of Linux distributions, however, the focus is on Firefox, X windows and anything that runs under a Free/Open Linux or *BSD system. Of course integration via Java applet (e.g. VNC, NoMachine NX) can be cross-browser.

      In addition, Firefox 3.0 will have some very impressive features for SaaS. If a "killer app"
      emerges that takes advantage of these facilities, it is not inconceivable to require installation of a free browser to gain improved functionality -- especially in organizations.

      Currently, alternatives to the browser seem underdeveloped (if they exist at all). Contrast this with using Python, for example, to replace the shell and friends. Here, the alternative is highly mature, so the migration path away from the older toolset is clearly visible.

      Developing an alternative SaaS platform could certainly be an interesting project. It would be very difficult, however, to do better than Firefox, even taking into account the architectural disadvantages of JavaScript/HTTP/HTML/DOM. Most likely, the browser model has not reached its full potential yet, so the most fruitful approach would be to improve its Web application capabilities, while integrating better with the local X-based desktop software.

      Of course, if you are aware of any sufficiently capable and mature alternatives to the browser, feel free to discuss them.