The new storage api is designed for two basic purposes - session storage and local storage.

Session Storage enables carrying out multiple transactions in different windows at the same time, in effect giving each window its own data store for current session.
While it sure is very helpful, the one that we find more interesting is local storage api.

Storing data on the client has been a challenge for Web developers for ages and HTTP Cookies have been the only way to accomplish that. Cookies do not handle this case well, because they are transmitted with every request - which is a performance hit if there is more and more data. Web Storage brings us the freedom to do this with local storage api.

Apart from uses like personalization or tracking user behavior, a much more significant one is caching data from your servers, on the client’s local machine. This allows you to avoid waiting for potentially slow calls back to your servers and minimizes the amount of data needed from your servers. It is often inefficient, insecure, or inappropriate to store that data on a server and this may amount to megabytes of user data, such as entire user-authored documents or a user’s mailbox.

The recommended storage space for each site is 5MB. This is way more than the 4KB space available via cookies. Stored data is accessible from multiple windows and lasts beyond current session and each site has its own separate storage area.

Another important aspect is the ease of use of the API. The Storage API is a classic name/value pair data structure. It has simple methods like getItem(name), setItem(name, value) and remove(name). For iterating over all of the name/value pairs, one can use the length property which gives you the total number of name/values pairs being stored, or go along with a key(index) method which returns a name from an array of all names used in storage.

It is already supported in the latest versions of all major browsers: Microsoft®, Internet Explorer®, Mozilla Firefox, Opera, Apple Safari, and Google Chrome. Even more importantly for mobile developers, it is supported in WebKit-based browsers like those found in the iPhone and phones using Android (version 2.0 or later) phones as well as other mobile browsers like Mozilla’s Fennec.

We, as developers, suddenly have a huge amount of storage space on the client. For mobile developers, it’s even more exciting as it really opens up the local caching of data. In addition to dramatic improvement of the performance of your application, local caching is key to enabling another new exciting capability of mobile Web applications - going offline.

1. Google Secure Data Connector - The SDC enables the deployment of Google Apps applications that user resources deployed inside an IT departments firewall. The idea is simple, even when a company is using Google Apps to host their email, documents, calendars etc., there might still be digital resources within the corporate firewall that users might need. A very simple example might be a telephone directory of clients, stored on a computer within the corporate firewall. Using the SDC, a Google Gadget can be created that can allow users access to this telephone directory from inside their email or google docs interfaces. Not only that, permissions regarding which user can access which resources can be defined using SDC, so an IT department can strictly control access privileges.

SDC is only available for Premier Edition or Education Edition Google Apps accounts.

2. Provisioning API - The provisioning API provides functions for creating, retrieving, updating and deleting user accounts, nicknames, and groups. Essentially, it can enable creation of custom admin panels for administrating Google Apps accounts for their admins.

Provisioning API is also available only for Premier Edition or Education Edition Google Apps accounts.

3. SML Single Sign On service - Security Assertion Markup Language (SAML) is an XML standard that allows secure web domains to exchange user authentication and authorization data. Using SAML, an online service provider can contact a separate online identity provider to authenticate users who are trying to access secure content. Essentially, this allows Google to ‘off-load’ the job of authenticating the user on another provider, whose primary responsibility might be to be a single window authentication service for all digital resources and facilities of a company. Very intelligent, and very useful.

From Google’s documentation on this service: ” Using the SAML model, Google acts as the service providerand provides services such as Gmail and Start Pages. Google partners act as identity providers and control usernames, passwords and other information used to identify, authenticate and authorize users for web applications that Google hosts. There are a number of existing open source and commercial identity provider solutions that can help you implement SSO with Google Apps.”

4. Email Migration API - Targeted at users who had earlier been using some other email service or provider, and would now like migrate to Gmail for their company. How it works is simple, a domain admin or user can send POST web requests to Google to enter data into their email accounts. There are also a wide variety of applications now available from Google to migrate email to Gmail from popular email software like Microsoft Outlook.

Again, Email Migration API is only available for Premier Edition and Education Edition Google Apps accounts, and can not be used to migrate Standard Edition email or gmail accounts.

We at Mobicules, being long time Google Apps users, have been playing around these API for some time build some internal tools. Get in touch if you think we can do something for you to make Google Apps work better and do more for you

We shall be discussing two frameworks here today - Symfony and CodeIgniter.

To first note down a few similarities between the two:

• Both the frameworks follow MVC architecture, which gives us distinct separation of code in terms of logic, view and database interaction.
• Use configuration files to help you maintain vital metadata, such as the location of the database, base URLs, and the like.
• Provides helpers classes for various features.
• Allow the developer to extend the core code and build their own libraries and helper functions.
• Both support caching, multiple databases, form support, form validations and other common features.

Both the frameworks are very similar in the sense that they allow a platform to the developer to easily create their application in minimum amount of time and effort. But they differ in terms of implementation and the features they provide.

• One of the biggest difference between the two frameworks is the ease of use. CodeIgniter is pretty easy to start with where as Symfony has a distinct learning curve and can be little difficult to start with.
• CodeIgniter has a very small footprint, which is only about 1MB where as Symfony comes to around 5MB. This is due to the fact that Symfony comes bundled with many 3rd party libraries (which one might not be using at all). This also makes Symfony slightly slower in the run-time compared to CodeIgniter.
• Installing Symfony can be tricky on shared hosting as it has PEAR dependency and requires shell/command line access for setting up projects, creating modules and other tasks, where as setting up CodeIgniter is as easy as copying the source folder on the server and changing a single line in the config file.
• Another area of difference between the two frameworks in the PHP version support. Symfony only supports PHP 5 where as CodeIgniter supports both PHP 4 and 5. This is due to the fact that Symfony is developed fully with Object Oriented approach.
• Symfony facilitates user with auto code generation for modules, models, database etc which is missing from CodeIgniter. Symfony comes bundled up with propel/doctrine ORM tool which provides wrappers for database functions. This feature is not available by default in CodeIgniter but can be integrated separately.
• Symfony provides in-built Ajax support, which is lacking from CodeIgniter.
• Debugging capabilities of these framework differ a lot. Symfony provides a debug toolbar in development mode which provides information about database connections, load time, parameters passed, session details among other things. This helps is analyzing and optimizing an application to a great extent. A similar feature is not available in CodeIgniter.
• Symfony CLI provides commands to quickly (and effortlessly) create an admin backend for the generated model classes. Again, no such feature is available in CodeIgniter.
• CodeIgniter is a simple and easy framework to use. It give the developer options to implement the application as desired and is flexible in implementation. Symfony on the other hand is a very powerful but somewhat rigid framework which follows convention where ever possible. Symfony is all about best practices whereas CI seems to take a more pragmatic route.

Whenever we compare things, we’ll always have pros and cons but that doesn’t necessarily make one thing better that the other. The same applies here as well. Both the frameworks have their own advantages/disadvantages and should be used according to the requirements.

In my opinion CodeIgniter works well for something quick and small, Symfony work wonders when it comes for complicated projects.

A Design Pattern is a known solution to commonly occurring problems or scenarios in software design. It is a kind of a template or structure on which one can code the application. It drills down in to the details relating to implementation of certain components. Benefits of knowing and using design patters are several. Patterns are known solution for building software systems. They can reduce development time as known solutions are used instead of reinventing the wheel. It is also a benefit to use known solutions that are tried and tested.

We, at Mobicules understand this and try to utilize design patterns where ever possible. We’ve developed many projects using the Symfony Framework, which implements the MVC pattern quite effectively. We’ve also made use of Symfony EventDispatcher, which is an implementation of the Observer Patter.

Implementing Singleton pattern (described below) with Ruby on Rails (another area of expertise at Mobicules), is as easy as adding ‘including Singleton’ in the class. This makes the class a singleton class and can be used throughout the application accordingly.
Below are the few popular design patterns which Mobicules have implemented in various projects:

Singleton:

This pattern is used in applications when only a single instance of a resource is required. Most common type of resource, on which this can be applied is database connection.

Using singleton pattern for database connection, the overhead caused for creating multiple connections is reduced.

MVC:

Model-View-Controller, this is the most commonly used design pattern. This patterns separates the business logic and presentation logic in such a way that any changes in the presentation logic should not interfere with the business logic and vice-versa. This is done with the help of a middle object called controller whose job is to take the request from the view pass it on the model and if required present the updated/new view to the user.

Factory Method:

Factory Method is a object oriented creational pattern.The method is used to create and initiate objects for classes. Use of factories gives the programmer the opportunity to abstract the specific attributes of an Object into specific subclasses which create them i.e. it defines an interface for creating an object, but let the subclasses decide which class to instantiate.

Observer:

The Observer pattern allows one object (the observer) to watch another (the subject). The subject object notify the observer object if the subject’s state changes (Conceptually, the Observer pattern in something like a trigger in a database, which runs a stored procedure when a table row is modified).

The main advantage of this pattern is that it decouples the observer from the subject. The subject doesn’t need to know anything special about its observers. Instead, the subject simply allows observers to subscribe. When the subject generates an event, it simply passes it to each of its observers which they can use in whichever way required.

There are many other creational/structural/behavioral patterns, like Iterator, Adapter, Prototype, State etc. But in order to implement a pattern effectively a detailed study is done at our end to understand the nature of the problem and how a particular design pattern solves it.

First the Social Plugins. Social Plugins enable functionality most of which was already possible using Facebook Connect, but Social Plugins make integration with Facebook much more uniform, simple and intuitive. With Social Plugins, site owners can very easily ‘embed’ Facebook related functionality into their websites, enabling user actions which can then reflect back on the user’s profile on Facebook. A few key points of note:

•  When they visit a site, even before they log in to the site using Facebook, they would be able to see their friends who are members of the site using Facebook, if the user is logged into Facebook from the browser.
• Users can comment on content on the site using functionality enabled by Facebook, and the comments would be visible on Facebook on the user’s profile.
• The Facebook “Like” button is going to be everywhere on the web, and would be an easy single step process for users to connect their facebook profiles with the content on the site.
• A very interesting Live Stream plugin can be embedded on your website to enable a live discussion between a Facebook user and his Facebook friends on your website

We’re sure a lot more would come soon. This paradigm of enabling connections can be stretched to a great length by Facebook to enable a lot of interesting functionality.

Whats next is the OpenGraph protocol, which is Facebook’s baby step (but a profound one) towards the semantic web. What it provides is a very simple way for any site to link itself up with Facebook content and pages, so that the sites can show up seamlessly and richly across Facebook - in search results, user profiles or newsfeeds. Site owners can now easily declare meta information on their site that can be picked up by Facebook and shown on newsfeeds, search results and user profiles. Site owners can not only define titles and descriptions for their pages to show up inside Facebook, but they can also direct Facebook as to which section or category on Facebook should the page appear under. Additionally, owners can also declare contact information using the meta tags, which makes it very easy to contact the site owners from inside Facebook. All this is fairly simply, and from what it appears, potentially very effective.

What has the developers interested is the Facebook Graph API. Other than the fact that it brings in a completely new way for developers to interact with the Facebook platform, what is of great interest is that Facebook now allows developers to cache Facebook’s data on their own servers for more than 24 hours, which was, till now, strictly disallowed. This has raised privacy concerns, and it will be interesting to see how Facebook handles it.

All in all, in our opinion, this appears to be the most important and biggest step in the Facebook system after the release of the Facebook API years back. The effect of this is going to be potentially explosive, and if this works out well, will make Facebook totally ubiquitous, probably even synonymous, with the web.

Voyavo is an application developed with latest web2.0 technology and cutting-edge user interface. Highly interactive and having all the social interaction features - Voyavo is just the right tool for all the travel enthusiasts for planning their trips. Apart from making trip management a piece of cake, Voyavo also helps you find the best and book flights, hotels, car hire and activities and you can easily add them to your itinerary.

Voyavo brings a more social travel experience with the ability to share proposed itineraries, watch for the best priced items, store travel bookings, and quickly develop a travel plan – to meet the needs of all travelers on a trip, before your book the travel details. Voyavo harness social networks and helps consumers to organize, share details and invite others to join in travel planning and search, book, post and share activities with friends, family and associates.

All of your restaurant reservations, day activities, flights, hotel stays and other details from your trip can be kept together and organized by day, and by week. Voyavo has a seamless integration with maps and you can even view your trip details in relation to each other - get directions to and from all your planned events. With a number of privacy options, you decide who can view what. Keep your own itinerary separate from everyone else. For group trips, you can keep a separate itinerary that is private from the rest of the group. You can also create other organizers to help plan the trip. You can also create a watchlist of fares & prices - Voyavo keeps track and notifies you of the best deals and prices of flights, hotels, and cars you add to your watchlist.

You can login with any of your social network or email accounts - connect to Voyavo with your MySpace, Facebook, Yahoo!, AOL/AIM, Gmail, OpenID, or Twitter account! You don’t need to create another set of login information you might forget! Invite your friends from Facebook and your address books to easily keep everyone up-to-date on travel plans.

Voyavo is developed using Symfony and JQuery - the latest in web technology. Symfony is a php-based framework designed on the principles such as DRY and KISS. It is the perfect tool for developing feature rich complex web applications such as Voyavo. It is also highly customizable with a wide range of plugins and an active community. JQuery is one of the most feature rich and customizable javascript library. It accelerates development to a great extent and helps you deliver a highly enhanced GUI to the users. Again, with a wide variety of plugins available, you can create a state-of-the-art interface to impress your consumers.

Choosing the right tools for development of a product is an essential part of its success. We at Mobicules understand this and recommend the best solutions from the industry.  The Internet is ever-changing and ever-expanding and so are the applications.

Goal

To select a platform/framework which will allow scaling to 10s of million users for a social application.

The core issue here is Database Scalability and Flexibility. We’ll touch upon both one by one:

Database Scalability: As it turns out, perfectly normalized, flat databases with absolutely no data/information duplication are not essentially right for applications that need to scale to a huge user base. Such a database structure needs excessive computation and a lot of table joins, which end up getting computationally very expensive as user base grows.

Database Flexibility: Complete control over database structure is required if one is to design an application that is needed to scale to a huge user base, as with time, different clustering and partitioning schemes might be required to help the application scale horizontally.

Platform Assessment

The following is an assessment of Elgg, Drupal and Symfony on the above parameters:

ELGG: Due to a very flat and normalized database structure, the only way to scale horizontally with ELGG is to duplicate the database using MySQL replication on multiple servers. The negative with this approach is that it ends up duplicating the complete database, with the result that each machine running a copy of the replicated database will have to be very powerful server, rendering the solution expensive. (MySQL clusters is a standard way of doing it)

Drupal: Similar problems as ELGG with Drupal, but database is not as flat and normalized as ELGG. Scaling up in a similar manner as described for ELGG wity MySQL clusters would probably be cheaper with Drupal.

Symfony: Allows us to use a custom database structure. We can design the database and replicate it as we like. Symfony also uses its own query/object caching mechanism, which is efficient. As an example, the Yahoo bookmarks site supports 20 million users on Symfony.

Proposed Solutions

Solution 1:
Get deep into the ELGG code and customize the database interaction layer so as to support our own database, that can be designed and partitioned as we wish. The problem that this approach comes bundled with is that subsequent ELGG updates/releases will not be directly usable by us, and we will have to manually merge them into our ‘custom ELGG’. The positive of this approach is that ELGG plugins will work on our ‘custom ELGG’ with none or very little changes, if any.

Solution 2:
Build the solution ground up with Symfony, with our own custom database design that allows us the flexibility to partition it as we like. 

Recommendation

Our recommendation in a case where you are looking to scale up to 10s of millions of users would be write everything from scratch (and not use a ‘platform’ like ELGG/Drupal), that allows you to customize and tweak anything and everything. Symfony seems to have a good reputation for enabling creation of very large websites, and so, we would recommend using Symfony as a framework.

With this experience in the background, Mobicules is now capable of designing, developing, deploying and maintaining rich kiosk multimedia applications and kiosk management infrastructure.