Monthly Archives: March 2012

About CUBRID

In general, CUBRID is a comprehensive open source relational database management system highly optimized for Web Applications, especially when complex web services process large amount of data and generate huge concurrent requests.

More specifically, CUBRID is implemented in C programming language. It is scalable and is a high performance database system almost fully compatible with MySQL. CUBRID is a system with a unique architecture and rich functionality. Its High-Availability feature, sync/async/semi-sync replication, online and incremental backup, and many other enterprise level features makes CUBRID a reliable solution ideal for Web services. By providing unique optimized features, CUBRID enables to process much more parallel requests at much less response time.

Why Use CUBRID

CUBRID has been developed since 2006, and today it is becoming very popular because of its clean and highly optimized for Web Applications Software Architecture, as well as rich database functionality. Its code base has undergone complete optimization and intensive quality assurance. CUBRID is being used by many SME companies and large organizations, the latter having a farm of over 10,000 data servers. (See Who else uses CUBRID?)

CUBRID, unlike other database systems, does not have an Enterprise version of its DBMS. It do not distinguish its license policy between Community and Enterprise. There is only one version of CUBRID DBMS, which follows General Public License version 2 or higher. This CUBRID Open Source License Policy is extremely beneficial for companies dealing with client applications development. They do not have to purchase any Enterprise License or share their income. This provides the organizations the significant cost savings opportunity over the alternative database management solutions. (See complete article on CUBRID Open Source License Policy.)

Total Cost of Ownership (TCO) for a CUBRID based database solution is significantly lower than the alternatives due to hardware costs savings. CUBRID’s high performance, its optimizations and perfect scaling mean that organizations can deploy cheaper hardware and still provide 24/7 up-time service for the same number of concurrent users.

Reference : http://www.cubrid.org/about

Comet Programming: the Hidden IFrame Technique

As covered in Comet Programming: Using Ajax to Simulate Server Push, Comet is a Web application model that enables Web servers to send data to the client without having to explicitly request it. Hence, the Comet model provides an alternate mechanism to classical polling to update page content and/or data. In that article, we learned how to use XMLHttpRequest long polling to refresh page components and keep cached data in synch with the server. Another Comet strategy, sometimes referred to as the “Forever Frame” technique, is to use a hidden IFrame. As with XMLHttpRequest long polling, the “Forever Frame” technique also relies on browser-native technologies, rather than on proprietary plugins or other special technologies.

IFrames Technique Overview

IFrame stands for Inline Frame. It allows a Web page to embed one HTML document inside another HTML element. As you can imagine, it’s a simple way to create a “mashup”, whereby the page combines data from several sources into a single integrated document:

1 <html>
2 <head>
3 <title>IFrames Example</title>
4 <meta http-equiv=”Content-Type” content=”text/html; charset=iso-8859-1″>
5 </head>
6 <body bgcolor=”#FFFFFF” id=body>
7 <h2 align=”center”>IFrames Example</h2>
8         The content below comes from the website http://www.robgravelle.com
9         <iframe src=”http://www.robgravelle.com/” height=”200″&gt;
10             Your browsers does not support IFrames.
11         </iframe>
12 </body>
13 </html>
view plain | print | ?

Normally, data delivered in HTTP responses is sent in one piece. The length of the data is indicated by theContent-Length header field. With chunked encoding, the data is broken up into a series of blocks of data and transmitted in one or more “chunks” so that a server may start sending data before it knows the final size of the content that it’s sending. Note that the size of the blocks may or may not be the same:

1 HTTP/1.1 200 OK
2 Content-Type: text/plain
3 Transfer-Encoding: chunked
4 23
5 This is the data in the first chunk
6 1A
7 and this is the second one
8 0
view plain | print | ?

In Forever Frame Streaming, a series of JavaScript commands is sent to a hidden IFrame as a chunked block. As events occur, the IFrame is gradually filled with script tags, containing JavaScript to be executed in the browser. Because browsers render HTML pages incrementally, each script tag is executed as it is received.

Two benefits of the IFrame method are that it’s fairly easy to implement and it works in every common browser. On the cons side, there is no way to handle errors reliably nor is it possible to track the state of the request calling process. Therefore, if you want to track the progress of the request, you’d best stick with the XMLHttpRequest method.

Continue reading →

Comet (programming)

Comet is a web application model in which a long-held HTTP request allows a web server to push data to a browser, without the browser explicitly requesting it.[1][2] Comet is an umbrella term, encompassing multiple techniques for achieving this interaction. All these methods rely on features included by default in browsers, such as JavaScript, rather than on non-default plugins. The Comet approach differs from the original model of the web, in which a browser requests a complete web page at a time.[3]

The use of Comet techniques in web development predates the use of the word Comet as a neologism for the collective techniques. Comet is known by several other names, including Ajax Push,[4][5]Reverse Ajax,[6] Two-way-web,[7] HTTP Streaming,[7] and HTTP server push[8] among others.[9]

Implementations

Comet applications attempt to eliminate the limitations of the page-by-page web model and traditional polling by offering real-time interaction, using a persistent or long-lasting HTTP connection between the server and the client. Since browsers and proxies are not designed with server events in mind, several techniques to achieve this have been developed, each with different benefits and drawbacks. The biggest hurdle is the HTTP 1.1 specification, which states that a browser should not have more than two simultaneous connections with a web server.[10] Therefore, holding one connection open for real-time events has a negative impact on browser usability: the browser may be blocked from sending a new request while waiting for the results of a previous request, e.g., a series of images. This can be worked around by creating a distinct hostname for real-time information, which is an alias for the same physical server.

Specific methods of implementing Comet fall into two major categories: streaming and long polling.

 

Reference : http://en.wikipedia.org/wiki/Comet_%28programming%29