Maemo – Qt – Google

Posted on by

ok so my proposal to the Maemo community is to integrate the google services in small reusable libraries in Qt( C++).

before i get along with the discussion on this proposal…let us look into some basic terminologies in designing such a framework.

Framework : Famework is a finite solution that help you structure your code and solve a particular kind of problems. A framework is usually made of several patterns implementation. A framework is based upon the IoC (Inversion of Control) principle; your application just need to provide and declare some callback functions and start the framework. From there the framework is in charge of running the application, calling your callback functions whenever it’s necessary. The main difference being that a framework is a physical and usable piece of code while a pattern is a logical design solution to a given kind of problem.

API : Application Programming Interface – API in general terms can be said as an interface developed to felicitate interaction with other software. In our case it’s the set of function calls which call up the Google Services is the Google API, whereas our API would be a set of functions which would hence call the Google API to access the Service.

Wrapper:- generates a high level API for a low level API for ease of user.

low level API – Google API

Wrapper- My project

Application- Any Qt/Maemo

Architecture– deals with association between things and components

Methodology– deals with interaction between things

REST– REpresentational State Transfer is a style of software a architecture for distributed hypermedia systems such as the World Wide Web. It exemplifies how the w

eb’s architecture emerged by classifying and constraining the interactions of 4 major components of the web

  1. origin servers
  2. gateways
  3. proxies
  4. clients

without imposing limitations on individual participants.

http://en.wikipedia.org/wiki/Representational_State_Transfer

JIITU LMS

Posted on by

here is a preview of the LMS implemented in my university on its network using Drupal and Google Apps

Features implemented ( Pre-alpha )

Registration Page (Profile Setup): Here the First name , last name are retrieved from LDAP structure and Concatenated  to make the Jiitu.org Google apps email Id.  In normal method, All new accounts registrations are queued in an Approval queue. Where only on admin’s approval, Google Apps account is created using Provisioning API. The Account creation part is currently done using independent scripts we have built. Thus currently is lacks the modular power which Drupal enables an admin. It need to converted into a Drupal module and hence generic, so that every one can use it .

Registration Page (Step 3): LMS Profile and Google Apps Account Details( username and password of the account registered using provisioning API. The user is also mail all his details to his secondary email id.

.LMS Dashboard

(a)    JIITU.org Mail Feeds ( need to be enhanced as stated in proposal )

(b)    JIITU.org Docs Feeds ( need to be enhanced as stated in proposal )

(c)    JIITU.org Calendar

(1)    The block of gmail and Docs . Though right now they are very primitive and made using Panels. They need to be highly enhanced and generic.

This is the latest thing done .  “open as Google docs” links comes aside every document that is attached. Currently we just made an script which upload the  document to the Google apps account of the Drupal user.  The Script , action and admin option needed to reframed into a small module. In future, Sharing and publishing property will also be configurable an option in attachment form ( make is public ,etc )

OAuth vs ClientLogin API

Posted on by

OAuth Vs ClientLogin Api

Google’s two basic approaches for authorizing an installed application to access google service and data .

An “installed application” is defined here as installed on a machine such as a desktop computer or a mobile device

CLIENT LOGIN API OAuth API
Google specific standard hence can be used only for Google services Industry standard hence can be used for other services other then Google
Security : User has to supply id and pwd to the 3rd party application On the login page , warning of unauthorized application displayed.
Login : Login behind the scenes Through the familiar Google Login Box
No flexibility Flexibility for multiple and hosted accounts
Only for installed applications For both installed as well as web applications

Authorization with the ClientLogin API is a step up from the “low-tech” approach, which required applications to include the user’s login name and password in every request to a Google service. With programmatic login, Google issues a token that can be referenced in all subsequent requests. This approach offers several advantages, including:

  • Performance is improved because login data is validated only once per session instead of with each request.
  • Security is tightened by minimizing the number of times login data is transmitted per session.
  • The authorization process can incorporate additional security measures, such as the use of CAPTCHAs™.
  • Authorization measures can be more easily enhanced and extended as required.

refer to Google Documentation for

Installed applications that need to access Google services protected by a user’s Google or Google Apps (hosted) account can now use the OAuth protocol for authorization, using Google’s newly released OAuth support for unregistered applications, and additional options for returning verification information back to the requesting application. OAuth offers a more secure authorization process than ClientLogin, and is a particularly valuable for developers working with multiple services supporting the OAuth protocol who can create a single OAuth-based authorization solution for all services.

refer to the following link :

Google’s Documentation

Sessions from Google I/O 2008