Wednesday, November 10, 2010

SCP&SSH to the Qemu runtime

MADDE stands for Maemo Application Development and Debugging Environment and offers the following features:


Command-line cross-compiling
Multi-platform support (Linux (32-bit/64-bit), Windows, Mac OS X)
Configurable for different targets & toolchains
Client for the device to simplify the development process


Mad is frontend to madde execution environment. 
Usage: mad [-t TARGET] COMMAND [args]
 COMMAND may be one of the internals listed below
 or system command (such as 'make')


  remote     command set to handle runtime
  info       print madde configuration in xml format
  query      query variables
  list       list components in cross-compilation environment
  set        set default target
  pscreate   create project skeleton


you can scp to the Qemu runtime using the following commands
The ssh port for Qemu is 6666.


"scp -P 6666 filename developer@localhost:/home/developer/ "
 (or) you can do 
"mad remote send  "filename"  "for copying files into Qemu
"mad remote remove "filename" " for deleting files from Qemu
"mad remote install" will install DEBIAN_PACKAGE on runtime
"mad remote uninstall" will uninstall DEBIAN_PACKAGE on runtime   


"ssh -p 6666 developer@localhost"  for logging into Qemu


Here notice the difference, 
for ssh use "-p" (lowercase)for scp use "-P"(highercase)


"mad remote poweron" , "mad remote poweroff "
will turn qemu on and off 


"mad remote shell" opens a login shell on Qemu runtime
"mad ping shell"  checks if Qemu runtime is up and connectable


"mad info"
Prints madde configuration to stdout. The output is in xml format based on schema documented in madinfo.xsd.


"mad list"  will list the components i.e all the targets and runtimes in cross-compilation environment
"mad set"  will set default target.

Wednesday, November 3, 2010

Accounts & SSO


Accounts & SSO(Single Sign On) Framework

The Concept of  “unified account model

The Accounts & SSO (Single Sign On) project provides a framework to implement a unified account management system with secure authentication functionality. The account and SSO subsystems are orthogonal, in a sense that they can be used independently of each other. 
Both come with C and C++
Through C (glib/GObject based) and C++ (Qt based) APIs for client applications.
Accounts(How Meego will handle account settings)
Firefox, Thunderbird, Empathy/Pidgin, F-Spot Picasa export plugin: different applications asking for the same data, your Google account settings. The Accounts framework introduced in MeeGo aims at simplifying this situation, allowing application writers to rely on a unified solution for storing/managing accounts settings.
A centralized accounts UI is used to create accounts and edit their settings, while applications are just left with the task of enumerating existing accounts and using them.
SSO(Single Sign On)
A system for centrally storing authentication credentials and handling authentication on behalf of applications as requested by applications. This is a not only a centralized secure password storage; it’s also a framework of authentication plugins which help applications to login to remote servers while preserving user credentials from being exposed to the application.
Overview of "Accounts framework"
The accounts subsystem provides a storage solution for user accounts. Applications which need to store and access user settings for the service they provide over a user account will use the Accounts API. All applications acting on user accounts (such as instant messaging, e-mail, calendar and social networking applications) can benefit of the unified account model provided by this framework.

Design of the possible UI for Unified Account Model

This framework makes it possible to have only one account UI for creating and editing all user accounts; instead of configuring part of the user’s Google (for instance) account in Thunderbird (for e-mail), Empathy or Pidgin (for IM), F-Spot (for photo/video sharing), etc., we'd like to offer the user the possibility to have all of an account’s settings in a single place, divided by sections specific to every service type.
So, we'd have one section with all the settings that are global for the account: username, password (although for password storing we'd recommend using the SSO framework, and just store the ID of the credentials in the accounts DB), display name, maybe avatar, and a switch to enable/disable the account.
Then, every service provided by the account would add its own settings (if any); for sure there should be a switch to toggle the service on/off, plus any settings that makes sense for the service. For instance, the image sharing section could contain a setting for the maximum image resolution to be used when uploading.
These service-specific sections could be implemented via dynamically loadable plugins, or constructed at run time from XML descriptions.
This account UI could be in the control panel of the device, but it could also offer some IPC so that applications could invoke it for configuring a specific service type; for instance, e-mail application could have a menu item “Edit e-mail accounts” which would bring a view of all the accounts providing the e-mail service, and only the e-mail sections of each account could be shown.

Signond single signon daemon

Single Signon Daemon development files Single Signon Daemon provides password storage and credential retrieving service for applications. Provides authentication plugins for passwords and NokiaAccount.