 There are quite a few reasons to like gadgets. They are usually free and open source by design. They use standard web technologies, such as HTML, CSS, and Javascript. They are -at least in principle- platform-independent and portable. Perhaps most importantly, they are easy to program and deploy, which makes them ideal for small personal applications. I am thinking about keeping oneself informed about the scores of one's favourite sports team, displaying local bus schedules, or aggregating social network feeds into a custom-designed widget that sits on the desktop. I am sure that every computer user can come up with an idea for a mini-application that they always wanted but never found. Gadgets are the obvious solution, as they have web connectivity and web technology built in.
The first question for the budding gadget developer is then which gadget
technology to choose. In an ideal world, there would only be a single standardised package format and only a single standardised API. This would allow gadgets to be used on any platform and the question of choosing a format would not even arise. Alas, we don't live in an ideal world and therefore different platforms and markets have produced different gadget formats. For example, there are Windows desktop gadgets, Linux desktop gadgets, Google gadgets, and gadgets designed to be integrated into web portals. We will look at the different types of gadgets and their use in brief.
Windows Gadgets
Formerly known as Windows sidebar, Windows gadgets are based on the widget engine for Microsoft gadgets, which runs on the Windows platform only. A minimal gadget contains an XML configuration file (gadget.xml) and an HTML file (main.html). Other web files can be added. These are zipped for distribution and the resulting file is renamed to *.gadget. Windows gadgets have access to a special API divided into three parts. 1. Gadget objects provide gadget state and event handling. 2. System objects provide access to files, network and OS functions. 3. Presentation objects provide visual functionality, namely background, image, and text handling. Many Windows desktop gadgets can also be run (with slight modifications) inside a Windows Live homepage. The latter don't have access to the system API and cannot modify the page's DOM object tree.
Apple Dashboard
Dashboard is an application that hosts widgets on a Mac Computer. The widgets are contained in an invisible layer that is activated by clicking on a dock icon, or by pressing a key. Like Windows gadgets, Dashboard widgets are based on standard web technologies. A typical dashboard gadget contains six files: a property list and a JavaScript containing the interactive functionality, and HTML and CSS files, a background image and an icon for the visual design. Dashboard implements a client server architecture with widgets running as clients. There are three classes of Dashboard widgets: Accessory widgets that are self-contained mini-applications like clocks, calculators, etc., application widgets that interact with an existing Mac application, and information widgets that retrieve information from the Internet.
Google Gadgets
As is the case with Windows gadgets, Google gadgets come in different flavours. They are based on the Google Gadget API and run inside an iGoogle page or can be embedded into any web page, usually by loading content from a remote server. Google gadgets can also be run on the desktop if the Google Desktop product is installed, which is a bit of a downer, because Google Desktop also contains desktop search functionality that constantly indexes your PC's filesystem and allows text searches on all of your files. The good news is that the latter functionality can be disabled. Furthermore, there are Google gadgets with enhanced capabilities for the (recently decommissioned) Google Wave application. Like Windows gadgets, Google gadgets consist of XML, HTML, JavaScript (lots of it) and other web files. The advantage over their Windows cousins is that Google gadgets are more platform-independent, since Google Desktop is available for Windows, Linux and Mac. Reusing web gadgets for the desktop (or vice versa) is also easier. The Java-like Google Gadgets API provides methods in the gadgets.* namespace for IO, string and JSON processing, skinning, and other functions. Developers can use the iGoogle gadget editor and gadget testing environment for creating gadgets.
Yahoo Widgets
Google's competitor Yahoo also offers a gadget technology called Yahoo widgets based on the Konfabulator product. Yahoo widgets are primarily intended to run on the desktop rather than inside a web page and to that end, users must install the Yahoo widget engine. Unfortunately, this product is closed source and only available for Windows and Mac. Like their cousins, Yahoo widgets are comprised of XML, HTML, JavaScript, CSS (and optionally Flash) and are zipped into a single *.widget file for distribution. The comprehensive Yahoo Widgets API includes functions for event-driven GUI programming, DOM processing, downloading web pages, and access to Yahoo services. It is even possible to create and use an SQLite database with Yahoo widgets or access OS-specific functions by running shell scripts on Windows or AppleScript on the Mac.
Linux/Unix Gadgets
There is a variety of widget engines available for Linux and the market seems to be highly fragmented. For the already mentioned Google gadgets, Linux users can download the open source Google-Gadgets-For-Linux software that allows Google gadgets to be run without Google Desktop. In addition, there are the following widget engines, among others, for which a limited choice of existing widgets is available:
Gdesklet - is a Gnome program for running gadgets on a Linux desktop. Despite its name, it can be also be used with other Desktop managers other than Gnome, like KDE or Xfce. Desklets are applets programmed in the Python language.
SuperKaramba - is a widget engine for the KDE desktop. The visual aspects of a SuperKaramba widget are specified in a text file, while its functionality can be programmed in either Python, Ruby, or JavaScript.
Screenlets - is a X11/Compiz-based widget engine that is independent of the desktop environment. It supports Python applets with skins drawn in SVG and -more recently- web widgets written in HTML, CSS and JavaScript.
 NoSQL databases have entered the radar of web application developers lately. While relational database management systems (RDBMS) have been powering almost every web application on the Internet for more than a decade, this is beginning to change. No longer is the selection of persistence technology a no-brainer. You have additional choices. Besides the old friend RDBMS, there are object-oriented databases, graph-oriented databases, key-value stores, column-oriented databases, and other options. Many of the newer products in this area are known as NoSQL databases. NoSQL is a movement that promotes persistence technologies that break with the conventional relational model. NoSQL databases typically don’t have tables schemas, SQL support, and are designed to scale horizontally.
For those of you old enough to remember Dbase, the NoSQL moniker may not be much of an attention grabber, because after all, products like Dbase, FoxPro, Clipper and similar DB systems never had SQL support either. With these systems, relations had to be expressed implicitly in the application and “queries” had to be coded as retrieval sequences. By contrast, modern NoSQL systems depart from the relational model and in many cases also from the tabular data structure, in order to serve use cases where traditional RDBMS fail in one or another way. A typical example would be a sparsely populated table that contains very few data in rows and columns. Such a table -if it grows to a large size- presents an efficiency problem to most RDBMS with resulting performance loss. In the remainder of this article, we will look at a few selected NoSQL databases and see which use cases they cater to.
CouchDB
Apache CouchDB is a document-oriented database that represents documents as JSON objects. CouchDB supports all data types supported by JSON, or respectively by Javascript. The JSON objects are not required to comply with schemas and can therefore be defined freely, which means that each JSON object can have a different structure. CouchDB supports queries by views. Views are aggregate functions and filters programmed in Javascript that follow the MapReduce algorithm. Views are stored and indexed in the database. CouchDB provides a RESTful API where every object (and any other item) in the database can be retrieved by an URL. It uses the HTTP POST, GET, PUT, and DELETE methods for CRUD operations. Other features include ACID semantics on basis of multi-version concurrency control, similar to RDBMS, which is optimised for a high number of concurrent reads, and a distributed architecture that allows for easy bidirectional replication and offline usage. CouchDB is thus designed from ground up for Internet use.
Neo4J
Neo4J is a graph database. As the name suggests, it is intended for use with the Java platform, which includes any language that runs on the JVM. Neo4J stores information in nodes and edges; the latter are called relationships in case of Neo4J. Relationships are always of a defined type. Both nodes and relationships can store properties, i.e. data. The Neo4J database is thus optimised for representing complex graph and network structures, such as a hierarchical object repository or a social network. It offers high-performance graph traversal operations for data access. Nodes can also be indexed and retrieved by key which enables more conventional style queries. Additional features include ACID transactions and transaction recovery, based on the Java Transaction API (JTA). Optional libraries can expose a Neo4J database as an RDF store where the node space can be queried using SPARQL. Neo4J is an embedded database with a small footprint that runs in the same JVM as the application.
Redis
Redis is a modern implementation of a persistent key-value store for general purpose use. Key-value store is a name for a simple key-based access mechanism that basically implements a dictionary (or map) data structure. Traditionally, such systems were used for caching and Redis holds its entire database in memory, which makes it ideal for applications that require ultra-fast data access. Redis allows not just plain string data but also allows sets and lists of strings in the data space. The system offers a number of special commands, such as atomic push/pop and add/remove operations for lists and set operations such as building union, intersection, and difference. Redis persists data either by asynchronously writing memory to disk, or by appending to a journalling file as data is written by clients. Additional features include easy master-slave replication and rudimentary sharding. Redis offers support for various languages, such as C/C++, Java, Scala, PHP and others through native drivers and APIs.
HBase
HBase is a free implementation of Google’s BigTable written in Java. It is not the type of database you would use for a blog or a forum software. HBase is a tabular data storage designed for massive tables in the Petabyte range with billions of rows distributed over a number of physical machines and thus optimised for horizontal scaling. HBase is part of the Apache Hadoop project, a framework for data-intensive distributed applications, inspired by Google’s MapReduce and GFS technologies. Hadoop supports the database through its distributed filesystem HDFS which provides built-in replication and MapReduce traversal for HBase tables of arbitrary size. Features include optimised query push down via server-side scan and get filters, a high performance Thrift gateway, an XLM-based RESTful Webservice gateway, Hadoop cascading, per-column probabilistic Bloom filters, as well as data warehousing and data analysis modules. Since HBase saves column families rather than columns and since empty columns are not stored, it is ideal for sparse tables with semi-structured data. Typical use cases are cloud computing and applications that require massive storage using cheap commodity hardware.
Db4o
Db4o is an open-source object-oriented database system targeted at OOP developers. The idea behind Db4o is to enable programmers to create and persist a representation of the application object model directly in the database without the need for an object-relational mapping software layer. Object instances can then be stored and retrieved with a single line of code. Db4o provides a query mechanism called Native Query (NQ). This allows querying data with native OOP language constructs thus offering type safety for query expressions while eliminating the need for building query strings. Db4o is available for the Java and .NET platforms. If used with .NET languages, data can alternatively be queried with LINQ (language integrated query). The Db4o database is embeddable with a small footprint suitable to be deployed on mobile devices. Additional features include semi-automatic schema versioning, transaction support with ACID semantics, and synchronisation/replication mechanisms that allow synchronisation between different Db4o instances and data export into SQL databases.
 As you can gather from the title of this website, I create software in Java, Scala, and PHP. While Java and Scala compile to bytecode that runs on the same virtual machine, PHP is executed by a separate interpreter. The most efficient way to run PHP scripts is to integrate the interpreter directly into the webserver. Hence, most PHP developers use a local Apache Httpd server with mod_php for development. If you also do Java programming, this raises the problem that you need two different web servers, namely Tomcat (or another web container or appserver) for Java development and Apache for PHP development.
Running two servers is a bit of a nuisance. Two servers consume more resources than one and you cannot run both on the same port. This problem can be solved in three different ways: you can only run one server at a time, you can use a different port number for one server which has to be included in the URLs, or you can integrate the two servers. There are again at least three different ways to accomplish the latter: you can proxy requests from Apache to Tomcat, you can proxy request from Tomcat to Apache, or you can use a connector module, such as mod_jk. Of course, maintaining two servers is is more complicated than maintaining one, and the integration adds additional complexity. Fortunately, there is an easier way to integrate PHP and Java web applications.
PHP/Java Bridge is a free open source product for the integration of the native PHP interpreter with the Java VM. It is designed with web applications in mind: Java servlets can “talk” to PHP scripts and vice versa. The official website describes it as an “implementation of a streaming, XML-based network protocol which is up to 50 times faster than local RPC via SOAP.” PHP/Java Bride requires no additional components to invoke Java procedures from PHP or vice versa. Although there are a number of different use cases, I am going to describe a particular one in this article, namely how to configure Tomcat with PHP/Java Bridge in order to have Tomcat serve PHP web pages. Let’s start with software requirements. We need the following software packages:
Follow the standard installation procedures for the JVM, Tomcat, and PHP. On Linux, you can use the standard packages for your distribution and on Windows you can use the regular installers. Make sure that both Tomcat and PHP are installed properly, which means that you should see Tomcat’s welcome web page at http://localhost:8080 and you should be able to execute a PHP script via the command line by invoking the standalone “php” command. The PHP/Java Bridge product does not use the regular executable, however, but fast CGI. The fast CGI executable is called php-cgi (or Php.cgi.exe on Windows), so you must make sure that your PHP installation contains it. Then you are all set to install and configure the PHP/Java Bridge.
The PHP/Java Bridge package comes with a sample web application named JavaBridge.war. Deploy the application in Tomcat, point your browser to http://localhost:8080/JavaBridge and try out the examples. If this works, you are half-finished. To provide the capability to execute PHP scripts server-wide, not just in a single web application, you need to make some changes to the Tomcat configuration. Find the three jar files named JavaBridge.jar, php-servlet.jar and php-script.jar (look in WEB-INF/lib) and move them to Tomcat’s shared library directory. This is usually found in $CATALINA_HOME/lib (or $CATALINA_HOME/shared in older Tomcat installations). Then edit Tomcat’s conf/web.xml configuration file and add the following lines:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
| <listener>
<listener-class>
php.java.servlet.ContextLoaderListener
</listener-class>
</listener>
<servlet>
<servlet-name>PhpJavaServlet</servlet-name>
<servlet-class>
php.java.servlet.PhpJavaServlet
</servlet-class>
</servlet>
<servlet>
<servlet-name>PhpCGIServlet</servlet-name>
<servlet-class>
php.java.servlet.PhpCGIServlet
</servlet-class>
<init-param>
<param-name>prefer_system_php_exec</param-name>
<param-value>On</param-value>
</init-param>
<init-param>
<param-name>php_include_java</param-name>
<param-value>On</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>PhpJavaServlet</servlet-name>
<url-pattern>*.phpjavabridge</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>PhpCGIServlet</servlet-name>
<url-pattern>*.php</url-pattern>
</servlet-mapping> |
This adds the listeners and servlets required for PHP script execution to all web applications. While you are at it, you might also want to enable index.php files to display when a directory URL is requested. Simply add it to the list of welcome files in conf/web.xml. My list looks like this:
1
2
3
4
5
6
| <welcome-file-list>
<welcome-file>index.html</welcome-file>
<welcome-file>index.htm</welcome-file>
<welcome-file>index.jsp</welcome-file>
<welcome-file>index.php</welcome-file>
</welcome-file-list> |
Now you can copy PHP scripts into the context root directory of any web application and type the script URL into your browser. I suggest you try a script with phpinfo(). It gives you plenty of useful configuration info. If this doesn’t work and you are on Unix, the problem might be file permissions. On my machine, I had to copy the contents of “java” directory in the JavaBridge webapp manually to the context root directory where PHP applications were installed. This directory contains two files Java.inc and JavaProxy.php. Normally, the PHP/Java Bridge software copies it automatically, but it might not be able to do so if it does not have proper permissions:
~$ ls -lh /var/lib/tomcat6/webapps/ROOT/java
total 136K
-rw-rw-r-- 1 root root 64K 2009-12-30 14:14 Java.inc
-rw-rw-r-- 1 root root 64K 2009-12-30 14:14 JavaProxy.php
Now try calling a PHP script. For example, a script containing the phpinfo() command displays information about the server:
I have configured my machine to host all PHP web applications in Tomcat’s ROOT context. This eliminates the extra path component of the webapp context, since the ROOT’s context path is “/”. Then I softlinked the folder that contains all my PHP projects into the ROOT webapp directory, so that the actual source files are kept separate from the Tomcat installation. In order to enable Tomcat to follow symlinks, you need to edit the context.xml of the respective web application -in this case ROOT- and add the line: <Context path=”/” allowLinking=”true” /> .
Another possible gotcha is Tomcat’s security manager, which is enabled by default on Ubuntu, but not on Windows. Although a security manager is not necessary for most development scenarios, it is highly recommended for production. I consider it good practice to enable the security manager on the development machine, because it allows me to recognise security problems early during development, before the application is deployed on the production server. The downside is that additional configuration may be required, for PHP applications to function properly. The respective configuration files are located in $CATALINA_BASE/conf/policy.d. Most likely, you need to grant PHP web applications write access to files in the document root and possibly other permissions, such as opening sockets, etc. It’s probably safest to do this on a per-application basis.
|
|
RSS Feed
