Pages

Comet - ajax broadcasting chat

I was playing around with the comet concept using jetty and dojo.I tried to make a sample app.We know that the mail updating feature of Gmail.It is done using Comet,meebo chats,google docs collaborative editing.The client does have a keep-alive connection to server.One of the popular comet implementation is done using Bayeux protocol.Its supported by dojo,jetty, servers like Weblogic ,Webspehere(uses dojo) etc.Comet is similar to Reverse Ajax by DWR or HTTP Push.If we are using the MIME type "multipart/x-mixed-replace" can be used to push different newer versions of document to the connected client (I think it was introduced in earlier versions of Netscape).

Ok I will explain how I did ...

Adding dojo to client as

dojo.require("dojo.io.cometd");
cometd.init({}, "cometd");
cometd.subscribe("/messages", false, "publishHandler");
publishHandler(msg) handles responses from server


In server

Bayeux b = (Bayeux)getServletContext().getAttribute(Bayeux.DOJOX_COMETD_BAYEUX);
Channel c = b.getChannel("/messages",false);
Client x = b.newClient("server_user",null);
c.publish(x,message, "new server message");
x.endBatch();

Every request mapped to comet/* will be handled by the comet implementation in jetty
In web.xml the servlet mapping is done as

<servlet>
<servlet-name>cometd</servlet-name>
<servlet-class>org.mortbay.cometd.continuation.ContinuationCometdServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>cometd</servlet-name>
<url-pattern>/cometd/*</url-pattern>
</servlet-mapping>
<servlet>
<description></description>
<display-name>PushServlet</display-name>
<servlet-name>PushServlet</servlet-name>
<servlet-class>com.comet.sevlets.PushServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>PushServlet</servlet-name>
<url-pattern>/push</url-pattern>
</servlet-mapping>

I didn't use dojo.publish(...) for publishing data.Instead i just used the GET method and
using a PushServlet i pushed data back to a connected client.We can develop the application in long -polling; in which the messages are sent to the server as the 'message' parameter of a application/x-www-form-urlencoded encoded POST request ; while callback polling , will sent messages as similar to JSON-P protocol where the callback function is passed to server as jsonp parameter.For comet applications a request is made, connection is established and subsequent reaponses are recieved by client.If Ajax is used there will be frequent request and response that would overload the server.


You can download the war.
add these libs
http://repository.codehaus.org/org/mortbay/jetty/jetty-util/6.1.5/jetty-util-6.1.5.jar
http://repository.codehaus.org/org/mortbay/jetty/jetty/6.1.5/jetty-6.1.5.jar

goto http://localhost:8080/comet_sample/test.jsp --- admin console
goto http://localhost:8080/comet_sample/client.html --- client console


Need to know about bayeux ? They have a written a draft on the protocol

http://svn.cometd.org/trunk/bayeux/bayeux.html

Another project where comet is used is Project Grizzly.Grizzly is a framework in java to build scalable servers .It uses Java NIO API. https://grizzly.dev.java.net/

For IBM websphere the comet implementation is done for WebSphere Platform Messaging (v6.0) included with IBM WebSphere Application Server Feature Pack for Web 2.0 Beta Program

History of Internet in PIctorial COmmunication Language

PICOL - PIctorial COmmunication Language is a project for providing free and open icons for electronic devices.I think a common pictorial language for electronic communication will make standardized icons of information.We know about the traffic sign boards.It will be interesting if we have this sort of representation in navigation!!
I saw this motiongraphics documentary made on PICOL icons... its awesome


History of the Internet from PICOL on Vimeo.

The Spatial Operating Environment

Computer graphics was first used in the film TRON and its been a wondrous friendship with machines and human creativity from then on.The user interfaces we have seen in Minority Reports to recent JamesBond film, was always a dreamy-reality to the audience.The stuffs of wild imagination can now be available for not much more than the cost of a high-quality mouse!!
John Steven Underkoffler was the science advisor behind the futuristic interfaces we saw in Minority Reports,Iron Man( HUDs and the credits were awesome).He is also the founder of Oblong industries.They developed g-speak spatial operating environment.As human civilization progress, amount of information he needs will be more than ever before to survive in this
planet.Its going to be huge amount of data... So the collaborative universe of information has to be presented in a revolutionary interface.Microsoft Surface,Iphone are known to many.Oblong developed a solution to the real-world problems using gestural i/o,spatial pixels as the g-speak environments .This is an excellent video showing the environment in action.It is not only UI.They do provide a scalable framework for large-scale applications.

Think about future workspace,classrooms,desktops,war rooms :P ....The cognitive science has always been interesting to me.The interface do provide a sort of synaesthetic sensation to perceive amount of data, than senses could do.A harmony of mind and machine.Computer graphics has been a wonderful field as it the looking glass through which we see computing as a science and the future of human mind...near god-like experience.

Design Patterns : Bridge

Bridge decouples the abstraction from implementation so that the two can vary independently.
Client which uses the classes inheriting the abstraction need not know about the service implementations.Bridge pattern abstracts the implementations’ interface from the application.
An example ? Consider database drivers. Removing the dependency from database vendors from the systems provides more flexibility.

Inheritance is a common way to specify different implementations of an abstraction. However, the implementations are then bound tightly to the abstraction,and it is difficult to modify them independently. The Bridge pattern provides an alternative to inheritance when there is more than one version of an abstraction.The Bridge Pattern is classified as a structural design pattern.This pattern helps to hide the implementation details giving more encapsulation.As the interface implementations and abstractions are decoupled , they can have hierarchies.Changing an implementation needn't require any compilation of abstractions or its clients.This provides a better layering structure than having the traditional abstract implementation of parent interfaces.

Sample Code:
http://bytescrolls-samples.googlecode.com/files/bridge-design.zip

More:
http://en.wikipedia.org/wiki/Bridge_pattern

About HATEOAS

I think designing a REST URL is really challenging The resources are represented as hyperlinks.When REST applications are to be designed do business logic states depend on REST URL design ? The changes in application state are done through hyperlinks.So every possible state of applications are exposed as services and state changes are also exposed as urls.So we can draw a graph depicting change in states.So the transitions are done at run time while using the application.It is decided by the server.So the hypermedia as the engine of application state (HATEOAS) becomes a design constraint.So if the server responds as a set of links depicting the transitions, the consumer client can traverse through them to arrive at the final state... Concept seems pretty straightforward, but are there any underlying implementation complexities ? The relationship between resources can be logical, but the server makes relationships for the application.The client can have states defined by hypermedia elements.The tags like IMG,OBJECT,SCRIPT embeds resource within itself.The CSS can have image background links.So these urls can locate to the resource globally.The name space is defined by web itself.I think the scene becomes more interesting when web service discoveries,ordering of interactions, business logic making the client dynamic by the features of this concept.The libraries and frameworks as we know provide a way to call a single function and the system itself calls other functions internally.So this form of calling a single URL as a an entry point for calling other related urls linking logic or resource states performs same functionality like an interactive website.The urls can change at any time.The urls become a constraint in designing for a dynamic application.There will be a tight coupling for the resources and the client due to these permanent urls which will have to be residing forever.So the solution ? The response can be documents of urls for the client to traverse as i mentioned above as to call the resource from a single entry point... which is what HATEOAS is about

With a truly REST based architecture you are free to change just about anything about the disposition and naming of resources in the system, except for a few well known start point URIs. You can change the URI shapes (for example, if you decide that you really hate the currently scheme). You can relocate resources to different servers (for example, if you need to partition you data). Best of all, you can do those things without asking any ones permission, because clients will not even notice the difference.

http://barelyenough.org/blog/2007/05/hypermedia-as-the-engine-of-application-state/