Contact

Tags

apis copyright patents sessions

Categories

Archives

Feeds

Building responsive sessions

Written by mufasa Thu, 31 Jul 2008 00:03:00 GMT

Categorized in Features with the tags  and no comments

First, what do I mean by sessions? The HTTP request/response model is supposed to be stateless but the vast majority of page requests employ some form of state, whether it’s for advertising or saving application state, implemented by using cookies or javascript. I take it as a given that this type of session state is necessary and would like to make these sessions as responsive as possible. Either because of network or rendering delay caused by the bloat of the current web stack, most sessions on the web are not very responsive. Developers today work around this using various hacks like AJAX or COMET but these often involve bringing in additional problematic technologies like flash or silverlight. A new thin client would take this into account from the beginning by being designed for responsive sessions from the get-go.

First, we have to let go of the page model. Every object on the screen should be able to be updated independently, just as AJAX tries to let the browser do now. This may cause some problems for the URL concept but URLs can be reworked to be used in different ways (I’ll write more about reworking URLs later). Second, we have to allow the connection to be stateful, as that describes most usage of thin clients. Remember, TCP is stateful and most network traffic runs over TCP, so it can be done efficiently. Third, we have to focus on rendering speed on the client and ditch all VM-based languages like javascript, silverlight, and java. Those languages have no place in a thin client anyway, as a true thin client only deploys graphical/view data. Finally, someday this may necessitate deploying new network protocols but for now I’m sure current protocols like TCP, SCTP, and IP should do the job.

We can do so much better at creating a usable thin client experience than we are doing now. Only apathy and ignorance cause people to continue using the outdated tools of the past rather than trying to build better tools and platforms. A new thin client could do this.

Questions:

Keeping the platform open

Written by mufasa Sun, 25 May 2008 23:55:00 GMT

Categorized in Open platform with the tags , ,  and 6 comments

In the past, software platforms have often been used to lock developers in. This led to a drive for open standards so that no one company could control the platform and to give all the implementers input into the standard. However, the standards process is largely a relic of hardware standards and doesn’t really work for application software. Standards are best suited to network protocols that are programmed into routers, routers for which the software then stays the same without being updated for years. The modern PC is updated very often, at least 2-3 times a year, so the standards process is a straight-jacket on desktop software. It takes years for the standards bodies to reach consensus on a standard, which once ratified shows the dents of design by committee and then cannot be modified easily. The inadequacy of HTML/HTTP shows the results of this process. I will now suggest a way to keep platforms open, open to developers and competition, without the standardization that chokes off innovation. I believe these concepts should be used for a new thin client but they can be applied to almost any new software platform, such as rich clients, widget toolkits, or other software libraries.

First, let’s look at each of the ways that companies can potentially lock up a thin client platform: APIs, copyright, and patents.

Taken together, these restrictions can make up an Open Platform Promise, or OPP, consisting of the following:

  1. No intellectual property rights will be asserted on any publicly disclosed APIs.
  2. Any APIs that are disclosed to one developer will be disclosed to all developers.
  3. No restrictions will be made on usage of the software to help reimplementation.
  4. All patents will be disclosed.
  5. No patent can preclude reimplementation of a feature of the platform.

Some may wonder why all this discussion of intellectual property is even necessary. My argument is that software platforms can be extremely widely deployed- a thin client platform in particular- so it is important to consider issues of lock-in and monopoly. Most current software platforms are either at one extreme of closed-source, patented software, exemplified by Microsoft and their win32 APIs, or the other extreme of open standards often implemented by open-source toolkits, exemplified by HTTP/HTML. The goal of the preceding is to fashion a melding of the two extremes that works better than either one does individually. I do not address the issue of open- or closed-source as I believe that most software will end up being a mix of the two. Instead, I address the other API and IP issues that go with keeping a platform open. The goal of the OPP is to allow developers of a platform to create something they can own and improve upon while allowing third-party developers the freedom to choose their platform and its implementation.

Questions:

We need a new thin client

Written by mufasa Wed, 14 May 2008 19:32:00 GMT

Categorized in Overview with no comments

We need to replace HTML. HTTP/HTML is an almost two decade-old prototype that has kept its basic form while many buggy and slow extensions have been mashed on top of it. It is now a hopelessly inefficient, quasi-rich client that does almost nothing well while maintaining a legacy language, HTML, that doesn’t do much and that nobody cares for. Worse, as an “open standard,” there are multiple incompatible implementations, either because the spec is vague or the implementers want to differentiate themselves. I would like to throw all this garbage out and start afresh with a new thin client. If we can get this right, maybe then we can start thinking about a rich client. Here is what I would like to see:

The essence of a thin client is to implement the most common GUI elements across multiple hardware and OS platforms while maintaining security. A thin client can be thought of as a first stab at ubiquitous network computing, where the security hassles of having the information superhighway coming into your PC- and the internet bandits and thieves who can now drive right up to your computer door- are handled by the thin client platform so that developers don’t have to. We can do much better at this than we are doing now. And finally, think of the children. If we don’t come up with a new thin client, what will we leave them?

I would like to hear more ideas on this subject from others and I will expand on each of the topics above in more detail. This blog is a place for discussion and sharing ideas, I would love to hear what others who also hold their nose at the current HTML/AJAX mess think.

Questions: