2007-01-03

Step #1 to Creating a WebOS: Proxy Server

Reading blogs this morning, I ran across Brad Neuberg's announcement that he is working for SitePen to create an off-line Dojo toolkit. I have to get ready for my day job now, but I'm excited enough that had to write something first. This is really step #1 to creating a WebOS.

I've mentioned in the past how a client-side server is required to create a proper WebOS. That seems to be exactly the approach Brad is taking.

An off-the-shelf, open source (GPL), C-based web-proxy will be used, named Polipo, saving months of development time creating a custom HTTP/1.1 proxy.
Deploying with a C-based solution seems like the wrong idea to me. I've toyed with something similar using Java and JavaScript to create a thin web server/proxy. I haven't been able to dedicate enough time to get it to the point I can demonstrate it. Keeping Dojo almost entirely in JavaScript, and using Java server implementations like Tomcat or Jetty, would seem more portable and supportable.

I also commented to Brad that Scrybe seems to do the off-line work without a proxy, though they may just be leaving that out of the demo information.

The great news, however, is that Dojo is a really popular open source toolkit and should get a lot of traction, even if it isn't on as many platforms as possible from the start. Brad also seems to be a really smart guy.

Posted by Jason Kridner at 7:44 AM

Labels: ,

4 comments:

  1. Hi Jadon! I'd love to use Java, which is my programming background, but how can I get the target download to less than 700K using Java? I looked at using SpiderMonkey, which is smaller, but the problem is there are no readily available HTTP/1.1 web proxies written in JavaScript, which are cross-platform, and I don't want to bite that off. If there is a way to get a Java-based web proxy compiled in a cross-platform way down to less than 700K I will consider it.
    ReplyDelete
  2. Brad,

    Chris Double's JavaScript web servlet consumes about 1,370K, but that includes the JavaScript interpreter written in Java:

    5,028 example.js
    481 JavascriptServlet.class
    1,777 JavascriptServlet.java
    65,681 jetty-util.jar
    433,245 jetty.jar
    701,049 js.jar
    4,125 readme.txt
    158,713 servlet-api-2.5.jar

    1,370,099 bytes

    I don't know exactly why you need to be under 700K. I'm sure it has something to do with the download time. It seems to me that 2-3X that wouldn't be bad.

    You should be able to strip out much of Jetty. You should at least contact Chris to see if he has an idea on how to reduce the size.

    You could also contact the Jetty experts at WebTide and Mort Bay. I'm not affiliated with them in any way. It is just my dream to do web development in one language. JavaScript is good enough to be that language and you don't have much choice in the browser today.

    You could also see if other servlet containers with proxy handlers have smaller footprints. Jigsaw and Tomcat come to mind.

    I think keeping Dojo cross-platform and in JavaScript as much as possible would be very welcome to web developers, even if it costs an MB or 3.
    ReplyDelete
  3. Jadon, I really appreciate you giving me the information about the JavaScript web servlet; I did not know about that. I encourage you to keep finding ways for me not to have to use a C based proxy, which I really don't want to do but I think is necessary due to size limitations.

    Why 700K? I believe it is mostly due to psychology; I have 10 years experience in Java, including a stint as a professional Swing developer, so I think I can safely say that Java has failed on the client-side (I know it is more sucessful in behind-the-firewall corporate applications, but consumer-grade technologies that are outside the firewall will always eventually eclipse "enterprise" grade ones inside the firewall, but that's another discussion...). I believe one of the important reasons Java has not suceeded on the client-side is the size of the download. I know that each meg probably only adds a few seconds (or perhaps a minute or two), but I think there is a psychological impact when someone sees the relative sizes of these downloads.

    As a counter-example, take Flash. Macromedia exercised great restraint in terms of the Flash plugins download size; it went frmo 700K to 750K through many versions, and I believe the size of the download was one of the important reasons it suceeded.

    Here's my challenge to you: if you can find a way for me to work in a high level language that has the following characteristics, then you will hav convinced me:

    * it must be a stable web proxy
    * I must be able to have it work cross platform (Linux, Mac OS X, Windows) -- just working on x86 is ok with me. If you compile the Java into native code, it must be done in such a way that I can compile it cross-platform, to my 3 target platforms. Further, the compilation technology must be stable for that platform (i.e. gcj can compile to Windows, but its not very well supported yet).
    * It must be less than a megabyte, and be self-contained. This would be its ZIPed file size, so its actual size can probably be more like 1.7 to 2 megabytes (depending on its level of compression).
    * It must be open source: BSD, GPL, LGPL, or something similar.

    I would be delighted if you can find a way to meet these criteria, so that I don't have to code in C. I don't like C -- I like Java, Python, JavaScript, etc., but I know there are things more important in the world than the choice of language, such as the size of the download for this particular kind of app.

    Best,
    Brad
    ReplyDelete
  4. BTW, I'm a big fan of Jetty -- I actually modified Jetty a few years ago to act as a web server that ran on a P2P network, on top of JXTA, in the P2P Sockets project -- http://p2psockets.jxta.org

    Best,
    Brad
    ReplyDelete

Subscribe to: Post Comments (Atom)