Announcing SeedKit project.

Those last few days, I had the oportunity to spend some time on my pet projects. Being far enough for now and waiting gladly for some external help, I am ready to announce one of them : SeedKit.

SeedKit is a runtime environment for hybrid Web-ui/GObject applications.

Taking advantage of Seed bug #612590, SeedKit provides a Webview whose Javascript context is filled with Seed-provided GObject symbols.

It makes possible the creation of a ui using standard Web technologies, such as JS, CSS3 and HTML5 bound to lower level events and behaviours of GObject based libs and DBus services (WIP).

All it requires is the path to an html file (defaulting to ui.html in CWD). This file can include js files calling into GIR-provided symbols.

You can pass --inspector to be able to inspect dom elements dynamically and --script=file.js for a custom initialization javascript file.
Some samples (Notifications, GIO, DBus...)are provided in the examples dir.

The project is still in its infacy and suffers from serious issues. Notably the DBus binding is not in a working state, seems like the js context is cleared after first-level imports or something.

TODO (as of now) :
- define a system-wide css file for common theming.
- add a developer mode, with reloading button

- create a bug tracker, an agile management tool, a website, ML
- fix DBus binding (exposes a customly created dbus connection within native code ?)
- add samples of web-services integration ( Evolution Contacts on a google map ?)
- a runtime for widgets ?
- see what s come next :)

The sources can be grabbed at http://gitorious.org/seedkit and you can mail me at scaroo@gmail.com, in the wait of a proper ML.

Any code, help or idea appreciated. Contributions welcomed :)

Cloud computing : vers une industrie de la transformation de ressources ?

A la lecture de cet article et dans le cadre d'un projet personnel, je me suis fais la réflexion suivante : proposer un service hébergé sur une plate-forme cloud n'est-il pas comparable à l'industrie de transformation de matières premières ?

Avant d'essayer d'y répondre, faisons un point sur ce qu'est le cloud, ou du moins la façon dont je l'envisage.

La tête dans les nuages

L'hébergement d'une application sur le cloud implique un paiement à la demande : seules les ressources réellement consommées sont facturées.

Les cycles CPU, le stockage et les transferts réseau sont souvent les ressources quantifiables, unités de la facturation.

Cette approche est à comparer avec celle, plus classique, consistant à payer un forfait mensuel, voire annuel, quelque soit la charge effectivement utilisée.

En outre, l'approche cloud apporte de l'élasticité, de la scalabilite puisque des ressources supplémentaires peuvent être allouées de manière (quasi-)transparente en cas d'un besoin ponctuel supérieur.

Enfin, une bonne partie des tâches d'administration et de garantie de disponibilité sont déléguées au fournisseur.

Ce modèle économique permet notamment de supprimer les frais initiaux (pas d'achat de serveur), de lisser et réduire les frais et de se concentrer sur le coeur de son métier, sans ce soucier des problématiques orthogonales que sont l'hébergement et la garantie de service.

Cloud Factory

Imaginons maintenant le cas d'un service web hébergé sur ce type de plate-forme. Imaginons aussi, dans un premier temps, que son fournisseur s'oriente vers une facturation forfaitaire de ses clients. Il parie donc sur le fait que le forfait mensuel payé par chaque client couvrira les coûts en ressources induits par son utilisation du service.
Il y a donc un risque que l'activité ne se révèle pas rentable, voire déficitaire. Le fournisseur peut minorer ce risque en misant sur la mutualisation et en imposant des règles d'utilisation limitant ce dépassement éventuel.

Il reste malgré tout une zone d'incertitude.

A contrario, l'éditeur peut opter pour une facturation à la demande, au même titre que ses propres frais d'hébergement. Ainsi, l'utilisateur ne paierait que la quantité de service auquel il a fait appel. Par exemple, un service de conversion de devises ou l'utilisateur serait facturé pour chaque conversion effectuée. Cette somme doit bien entendu être définie en fonction du coût engendré par une telle requête.

Avec un peu de recul, on peut dire que le fournisseur effectue la transformation, la combinaison et la valorisation de ressources brutes (CPU, réseau, mémoire, stockage) en produit transformé (conversion) consommable par l'utilisateur. Le tout en flux tendu. Ces produits sont alors vendu sous forme packagée, de manière unitaire et sans le moindre stockage.
Cela vous rappelle quelque chose ? Et oui, l'application hébergée sur le cloud est foncièrement devenue une usine de transformation comparable à celles du secteur de l'industrie ou de l'agronomie.

Du coup, il serait judicieux de s'appuyer sur les nombreux enseignements, modèles et outils du domaine industriel pour optimiser son activité de prestation de service sur le cloud. Non ?

EDIT : rephrasage, correction de fautes.

A plead for a SSB generator and execution environement for Gnome

This paper describes a proposed solution for a SSB system aimed at the Gnome Desktop. Having various web applications more tightly integrated within the user desktop would be a step toward the unification of the web and the native world.

What is an SSB ?

dixit Wikipedia : '
A site-specific browser (SSB) is a software application that is dedicated to accessing pages from a single source (site) on a computer network such as the Internet or a private intranet. SSBs typically simplify the more complex functions of a web browser by excluding the menus, toolbars and browser chrome associated with functions that are external to the workings of a single site.
'
What are the benefits of an SSB compared to standard browsing ?

• Space fully dedicated to web application content
• System integration (application launcher, notifications, menu, icon badges, local storage...)
• Standard windows' interaction, being handled by the WM/Shell

Existing Solutions
The SSB approach is already applied by several solutions, with diferents objectives and technical directon :

• Mozilla Prism : firefox extension allowing the creation of a SSB from the currently browsed web page. Of course, the execution environnement is built around Gecko.
• Fluid : standalone SSB creator and Webkit based execution environment with system integration (dock icon badges, Growl notification) and some goodies (userscripts, custom CSS)
• Adobe Air : Support application development using standard web technologies, beside Flash content. Embeds WebKit.

Proposed Solution

• a Webkit based SSB execution environnement, a chromeless WebView providing sytem integration
• An Desktop entry creator, following http://standards.freedesktop.org/desktop-entry-spec
• an Epiphany extension creating an SSB from the currently browsed Web App.

Desktop entry creator

• Generates .desktop file from user-defined values for the URL, the name and icon path of the SSB
• Provides right arguments to the execution environnement
• Defaults to Website favicon if no icon specified

Webkit based SSB execution environnement :

• One process per SSB
• Chromeless WebView
• Restricted access to the user-defined Web App domain
• Each SSB has their own cookie storage
• Use site specific javascript logic for system integration (ex: get the right value in the DOM for the number of unread messages to be displayed in the notification and/or badge)

System Integration implementation

• Applications launcher in Gnome menus
• Icon Badge (ex : number of unread mail)
• Notification system integration with libnotify using Seed or GtkWebkit DOM bindings ("You've got a mail")
• Application menu by generating specific GtkBuilder files and linking event using Seed or GtkWebkit DOM bindings
• Local storage, possibly Google Gears

The project will be hosted on Gitorious and welcome any contribution being code, documentation, or simply advices.

The first draft code will be commited sometime in the next week, the current state being nearly none :)

What if GTK+ 4.0 was ... HTML/CSS/Javascript ? Part I

Following recent activities on the GTK theming/graphical overhaul front, this post exposes some of my thoughts on a possible evolution path.

This first part explains some of the current identified short-comings and tries to dress the profile of the ideal UI toolkit. In the next post I'll try to explain the technical possibilities to go further this road.

Nowadays, GTK+ and most of the competing toolkits keeps the user interface creation a developer's affair when the web allows designer and usability experts to directly influence the aspect of the application. This is mainly caused by a steep learning curve and a lake of user friendly authoring tools.

Also recent efforts by the web standards bodies make them very appealing solutions for highly graphic, dynamic and interactive interfaces.

Current State :

GTK+ is the graphical toolkit used by several mainstream software projects. In a non-exhaustive way, we can cite the Gimp, the Gnome Desktop, Firefox and Openoffice.org (in their Linux incarnations).

It provides developers a way to programatically define/design the user interface of their software : where to put a button, a text entry or a selectable list for example.

It is also possible to declaratively define a GTK UI using the Glade editor and the GtkBuilder XML dialect. The coder binds the events generated by the UI elements (or widgets) to «business» code/services.
GTK+ currently misses some features found in more «modern» toolkits like animations support, canvas, free form layout, declarative theming.

GTK+ is built using GObject which bring dynamic object oriented concepts to the old-but-good C without scarifying the ability to easily bind the code to higher level languages like Python or Javascript.
The GObject ecosystem spun a lot of interesting technologies in the form of libraries mostly developed within the Gnome project. To name a few, we can cite the GStreamer multimedia framework, GIO, Avahi, EDS, PolicyKit.
The fact that GTK+ and those services share a common object system makes them easy to integrate in a GTK app, and thus help GTK+ staying relevant.In the same vein, GTK+ UIs can easily be plugged to DBus services.

New efforts to make the theming system more flexible like a CSS theme engine. By this leave flexible layouting on the side.

Some discussion is also going on the future of the metacity theming.

Pros :

• Multi-platform
• Community and commercially backed (Red Hat, Novel, Mozilla Foundation)
• Lots of language bindings
• Wide range of target system : Nokia Maemo, Moblin, Gnome, OpenMoko...
• Mature and alive code-base
• Rich eco-system of GObject libraries (DBus, GStreamer, GIO, Avahi, EDS, PolicyKit...)
• Enforce a coherence under most linux boxes

Cons :

• shrinking numbers of contributors
• Hard to grasp as mainly programatic
• Lake of "Bling" and usability/artistic freedom : canvas, animation/transition, freeform layout, declarative theming

Summing up, the ideal UI toolkit would :

• be multi-platform
• be community and commercially backed
• have a lots of language bindings
• be avalaible on a Wide range of target system
• have a Mature and alive code-base
• could benefit from the rich eco-system of GObject libraries
• enforce a coherence under most linux boxes
• have a big following, including developers, users, authoring tools
• be Declarative
• have very flexible styling and layouting
• provide advanced graphical capabilities as animation, transformation etc...

But wait... Doesn't HTML/Javascript/CSS match most, if not all, of these criterias ?