mardi 29 novembre 2011

-1 (une fois de plus) pour la Turquie


DANS CERTAINS PAYS,
UTILISER CET ORDINATEUR PEUT
VOUS CONDUIRE EN PRISON

Pour la liberté de la presse et de l'information > J'agis - Je fais un don
Reporters sans frontières pour la liberté de l'information
TURQUIE : LE PIONNIER DE L'ÉDITION EN PRISON JUSQU’À NOUVEL ORDRE
Journaliste de renommée internationale et figure respectée de la lutte pour les droits de l’homme, Ragip Zarakolu est aujourd'hui victime du détournement de l’argument "antiterroriste" par les autorités turques.

Défendant les droits de la minorité kurde dans ses ouvrages, il a été incarcéré le 1er novembre 2011 à la prison de Metris à Istanbul.

Aucun motif officiel d’arrestation n’a été pour l’instant établi. Selon son avocat, il a été interrogé sur plusieurs articles publiés dans une revue pro-kurde, et sur des voyages effectués à l’étranger.

Agé de 63 ans et de santé fragile, Ragip Zarakolu a besoin de notre soutien !

Storage, l'éternel problème ...

HTML5 : cap sur le stockage des données en local



Web Storage ou DOM Storage : quels avantages ?


Web Storage (ou DOM Storage) ajoute la capacité au navigateur de stocker et organiser des données locales. Ce concept initialement intégré à la spécification HTML 5, fait désormais l'objet d'une spécification séparée.

From Wikipedia, the free encyclopedia :

Web Storage and DOM Storage (Document Object Model) are web application software methods and protocols used for storing data in a web browser. Web storage supports persistent data storage, similar to cookies but with a greatly enhanced capacity[1] and no information stored in the HTTP Request Header [2]. There are 2 main web storage types, local storage and session storage, behaving like Persisted Cookies and Session Cookies accordingly.
Web storage is being standardized by the World Wide Web Consortium (W3C). It was originally part of the HTML 5specification, but is now in a separate specification.[3] It is supported by Internet Explorer 8Mozilla-based browsers (e.g., Firefox 2+, officially from 3.5),[4] Safari 4, Google Chrome 4 (sessionStorage is from 5), and Opera 10.50. As of 14 July 2010 only Opera supports the storage events.[5]

Les bénéficiaires de cette avancée sont bien entendu les applications Web qui vont tirer parti de structures facilitant la mémorisation de (relativement) grandes quantités de données sans devoir exploiter les cookies ou le dialogue constant avec une base de données distante, en Ajax par exemple.


sessionStorage et localStorage permettent de faire persister les données de l'utilisateur
Or, les cookies ne sont que des miettes. Ils sont familiers à tout un chacun, depuis les débuts du Web à destination des particuliers. Ils ont été employés pour la gestion de paniers virtuels dans le cadre de l'e-commerce, pour la mémorisation d'identifiants de sessions, et surtout pour pouvoir établir des statistiques de visites en suivant l'internaute au fil de sa navigation.

Leur inconvénient est de ne pas être adaptés au stockage local de données plus complexes :
 Ils engendrent un trafic HTTP supplémentaire en ajoutant leur contenu à chaque requête (quel que soit l'objet demandé, que les cookies lui soient utiles ou non), ce qui peut influencer les temps de réponse, notamment avec Ajax.
 Leur taille est limitée, habituellement quelques kilo-octets.

Le plugin Flash est également équipé d'un équivalent nommé Flash Local Storage, qui nécessite cependant le développement dans ce langage, qui n'est pas aussi simple d'accès, et qui reste subordonné à la présence du plugin.
Faire appel à Ajax et à une base de données côté serveur est envisageable, mais engendre un trafic réseau plus important, une exécution obligatoirement en mode connecté et une mise en place plus complexe.

accès à deux espaces de stockage







 
Accès à deux espaces de stockage © Eyrolles







 

Web Storage quant à lui met en œuvre deux objets nommés sessionStorage et localStorage pour faire persister les données de l'utilisateur respectivement durant la session ou sans limitation de durée particulière. La capacité offerte est nettement supérieure, habituellement de 5 Mo à 10 Mo par défaut, bien que cette limite puisse être modifiée au sein du navigateur. Les données ne sont alors plus véhiculées sur le réseau à chaque requête HTTP, et disposent d'une interface de programmation complète pour pouvoir y accéder en lecture, modification et suppression, de façon bien pratique.

Web Storage : Accès à deux espaces de stockage


La manipulation des objets Web Storage s'effectue exclusivement par des scripts exécutés côté client par le navigateur.
Ces données ne sont pas divulguées au travers des requêtes HTTP, lors de l'envoi ou de la réception de documents HTML, elles ne sont donc pas communiquées au serveur. Celui-ci ne peut pas non plus "directement" y écrire des informations à l'aide des en-têtes HTTP ou du langage interprété (PHP, Java, .NET, etc.).
Deux espaces de stockage existent, et diffèrent par leur portée et leur durée de vie.

Stockage de session


Le stockage de session (session storage) est destiné à la mémorisation de données ayant une courte durée de vie, dont la portée est limitée à la session active de la fenêtre (ou de l'onglet) du navigateur ainsi qu'au domaine dont elles sont issues. Il permet ainsi d'exécuter des applications Web dans des fenêtres (ou des onglets) distinct(e)s avec des ensembles de données différents sans risque d'interférences – ce qui n'est pas le cas des cookies. Les données sont effacées après la fermeture de la fenêtre (ou de l'onglet) et ne persistent pas. À l'ouverture d'une nouvelle session, dans une nouvelle fenêtre ou un nouvel onglet, le navigateur initialise un nouvel objet de stockage.

L'accès se fait via l'interface sessionStorage de type Storage, enfant direct de l'objet window, ce qui signifie qu'il s'agit d'un objet global au même titre que la plupart des autres API et interfaces d'accès aux outils de navigation (historique, cookies, etc.), et qu'il est accessible depuis un éventuel élément iframe contenu dans le document.


Local Storage



À la différence du précédent, le stockage local bénéficie d'une durée de vie plus longue puisqu'il n'est pas effacé à la fermeture du navigateur. Sa portée est étendue à toutes les pages et tous les scripts provenant du même domaine, dont il est issu ; donc virtuellement, à toutes les fenêtres et tous les onglets ouverts exploitant des pages hébergées avec le même nom de domaine. Hormis ces caractéristiques, il demeure fonctionnellement différent du stockage de session. Il est accessible via l'objet global localStorage de type Storage, enfant de l'objet window.


L'interface Storage de HTML5


Pour accéder de manière unifiée à sessionStorage et localStorage, l'interface Storage a été définie. Le modèle de données est un tableau associatif de paires clé/valeur, accessible par trois fonctions nomméessetItem(), getItem(), removeItem() :
 setItem(cle,valeur) : stocke une paire clé/valeur ;
 getItem(cle) : retourne la valeur associée à une clé ;
 removeItem(cle) : supprime la paire clé/valeur en indiquant le nom de la clé.

Toutes les valeurs sont de type chaîne de texte (String). Bien qu'elles puissent être lues directement via les propriétés de l'objet Storage, comme tout autre objet JavaScript, il est fortement recommandé de s'en tenir aux méthodes prévues à cet effet.
L'interface Storage est aussi munie d'une propriété length et de deux méthodes complémentaires :
 length : nombre total de paires clé/valeur stockées ;
 key(index) : retourne la clé stockée à l'index spécifié ;
 clear() : efface toutes les paires.


L'outil essentiel pour expérimenter Web Storage reste la console JavaScript, fournie par tous les bons navigateurs avec leurs extensions de développement, par exemple Firebug pour Firefox (onglet Console) ou les Outils de développement sous Google Chrome. Elle permet de s'assurer du bon fonctionnement de l'interface, de consulter à un moment donné l'état du stockage et de le modifier.

déroulé dans la console de firebug




Stockage, lecture, suppression avec Web Storage


Les exemples suivants exploitent à la fois stockage local et stockage de session, mais il est évidemment possible d'utiliser l'un sans faire appel à l'autre.

Stockage avec setItem()
// Mémorisation d'une valeur dans la session courante
sessionStorage.setItem("identifiant","Sibelius");
// Mémorisation d'une valeur dans le stockage local
localStorage.setItem("derniere_visite",new Date());

Le premier argument de setItem() est la clé. Elle nomme l'emplacement où l'on souhaite stocker les données pour pouvoir les y retrouver. Si une valeur numérique (par exemple 2) est utilisée comme clé, elle se voit obligatoirement convertie en chaîne de texte (soit "2") avant d'être utilisée.
Le deuxième argument est la chaîne de caractères à stocker. S'il ne s'agit pas d'une variable de type string alors le navigateur tente de convertir le tout au préalable, avec la méthode toString().


Lecture avec getItem()
// Lecture d'une clé de la session courante
var id_utilisateur = sessionStorage.getItem("identifiant");

// Affichage
alert("Identifiant utilisateur : "+id_utilisateur);

// Lecture d'une clé du stockage local
var date_visite = localStorage.getItem("derniere_visite");

// Affichage
if(date_visite!=undefined) {
alert("Dernière visite : "+date_visite);
}

La récupération du contenu est possible grâce à la clé initiale, fournie en argument à la méthode getItem(). Les données stockées sont renvoyées sous la forme d'une chaîne de caractères.


Suppression avec removeItem()
// Suppression de l'élément de session "identifiant"
sessionStorage.removeItem("identifiant");

// Suppression de l'élément de stockage local "derniere_visite"
localStorage.removeItem("derniere_visite");

Il ne faut pas hésiter à effacer les données devenues inutiles, l'espace total réservé étant de taille limitée. La méthode removeItem() est prévue à cet effet pour supprimer l'emplacement défini par la clé, ainsi que son stockage.


Suppression totale avec clear()
// Suppression complète de toutes les valeurs de session
sessionStorage.clear();
// Suppression complète de toutes les valeurs de stockage local
localStorage.clear();

Cette méthode n'affecte bien sûr que le stockage effectué à l'origine du document. Toutes les données mémorisées pour www.alsacreations.com, www.alsacreations.com:80, et www.alsacreations.com/html5/ sont concernées, mais pas celles des autres origines, par exemple un sous-domaine forum.alsacreations.com.

En matière de sécurité, il est recommandé de faire très attention à la portée de l'accès des données. Si celles-ci sont accessibles sur tout un domaine www.exemple.com, et que plusieurs développeurs différents ont accès à des sous-répertoires de ce domaine, par exemple dans le cadre d'un hébergement mutualisé sur www.exemple.com/le_site_de_roger/, et www.exemple/le_site_de_pierre/, ils peuvent lire mutuellement l'intégralité de leurs stockages respectifs. C'est pourquoi il vaut mieux éviter Web Storage dans ce cas de figure spécifique.

Un compteur de visites avec localStorage


Étant établie la persistance des données de localStorage au travers des visites successives, il serait tout à fait possible d'imaginer un compteur s'incrémentant à chaque consultation d'un document HTML.


Exemple complet



HTML5 : Web-Storage





Vous avez vu cette page
un nombre indéterminé de
fois.


Une précaution consiste à tester la présence de l'interface localStorage avec l'instruction typeof qui renvoie ?undefined' si le navigateur ne la comprend pas.

À l'aide de ces quelques fonctions de base, les possibilités sont infinies. Veillez cependant à en faire bon usage; si les ordinateurs de bureau actuels disposent d'une marge de stockage confortable, ce n'est pas nécessairement le cas de tous les périphériques mobiles.



Surveiller le dépassement de quota de stockage HTML5


L'espace alloué n'est malheureusement pas infini. Au moment de la rédaction de ce chapitre, deux pans de Web Storage demeurent flous et implémentés de façons différentes dans les navigateurs :

 la gestion des exceptions, c'est-à-dire la connaissance des erreurs potentielles lorsqu'une opération n'a pu être menée à bien,
 et la connaissance de l'espace restant.
Pour les implémentations complètes, une exception de type QUOTA_EXCEEDED_ERR est déclenchée si une tentative (infructueuse) d'écriture dépasse la limite. Placer les instructions dans un bloc try/catch JavaScript permet d'effectuer un essai de stockage, et d'attraper l'exception le cas échéant.


Détection du dépassement de quota
try {
  localStorage.setItem("data",
"0100000101101100011011000010000001111001011011110111010101110010001000
00011000100110000101110011011001010010000001100001011100100110010100100
00001100010011001010110110001101111011011100110011100100000011101000110
1111001000000111010101110011");
} catch(exception) {
  if(exception == QUOTA_EXCEEDED_ERR) {
    alert('Limite de stockage atteinte');
  }
}

Dans ce cas, la donnée n'est pas sauvegardée, et il faut faire de la place avant d'effectuer une nouvelle tentative.

Un soupçon de JSON



Il faut bien garder à l'esprit que tous les échanges concernent des chaînes de texte. C'est pourquoi l'exemple précédent doit faire appel à la fonction JavaScript parseInt() pour convertir les données stockées sous forme de caractères en nombre entier.

Toute variable étant au préalable convertie en texte grâce à sa méthode toString, la tentative de stockage et de lecture d'un objet JavaScript "commun" produira le résultat d'une simple conversion de cet objet en texte : "[object Object]". Pour passer outre, il faut employer le format JSON (JavaScript Object Notation), dont tous les navigateurs à la page sont équipés nativement. Ce dernier linéarise en une seule chaîne toutes les propriétés de l'objet.
Ce format est très courant dans la conception d'appels Ajax, notamment à l'aide de jQuery.

En savoir plus



RESSOURCE Spécification Web Storage par le W3C et WhatWG
 http://www.w3.org/TR/webstorage/
 http://dev.w3.org/html5/webstorage/
 http://www.whatwg.org/specs/web-apps/current-work/complete/webstorage.html
Pourquoi Web Storage ne figure pas directement dans la spécification HTML 5 ?
 http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-January/030110.html

Ces bonnes feuilles sont tirées de l'ouvrage "HTML 5 : Une référence pour le développeur web" écrit par Rodolphe Rimelé, et publié aux éditions Eyrolles. 













Jason about VUI


Why Apple is about to build, buy, or partner on a web search engine


November 29, 2011, 1:26 AM PST
Takeaway: Apple’s Siri could change the game in search and put a lot of pressure on Google, but first Apple needs to deal with web search integration.
Apple’s iPhone 4S was a disappointment to all of those who were expecting a redesigned iPhone 5, but in the grand scheme of the things the launch of the iPhone 4S may turn out to be Apple’sChamber of Secrets.
Forgive the Harry Potter reference, but Chamber of Secrets is the second book in the seven-book Harry Potter series, and while it’s generally the least favorite of the books among Potter fans, by the time you get to the final book you realize that Chamber contained critical plot information that foretold important future events.
The fact that the iPhone 4S was an incremental hardware upgrade and lacked a new design has largely overshadowed its one revolutionary feature that could shape Apple’s future: Sirivoice commands and voice-activated search.
Apple has limited Siri to the iPhone 4S to start, but that probably has less to do with Siri needing extra computing power on the phone and more to do with Siri still being in beta. Since Siri requires a cloud connection, limiting Siri’s spread at first gives Apple the opportunity to stress-test its data centers and scale up for the future.
Even with its beta quirkiness, Siri is impressive. While Google Android and Windows Phone 7 both had a jump on the iPhone in terms of voice control, Apple has zoomed past both of them with thepurchase of Siri and its integration into the iPhone. The big deal for Siri is that it understands natural language and it is standardized across a lot of different applications on the iPhone. The user doesn’t even have to be aware of which apps to use. You can simply give Siri a natural language command and she automatically interacts with the right app to execute it. That’s a nice step forward for voice user interface (VUI).
The Siri experience hearkens back to the launch of the original Macintosh in 1984 when Steve Jobs climaxed his unveiling by saying, “I’d like to let Macintosh speak for itself” and it did (using Macintalk software), which blew the minds of techies at the time. Of course, in a larger sense, the whole thing also points back to the computer in Star Trek and its VUI. In other words, Apple has been entranced by the idea of integrating speech into everyday computing for a long time — almost from the beginning of the company.
However, as fun as it is to bark orders at your phone and have it obey your commands in real time, the revolutionary piece of Siri is what it does in Internet search. It’s early and Siri is still imperfect, but there are moments when Siri drastically streamlines the search process and gives us a peek at the future.
For example, I recently asked Siri for “the closest Mediterranean restaurant” (right) and got a list showing 11 restaurants, their user ratings, and their distance from my current location. Clicking any of the selections in the list immediately took me to a map.
Another time, I asked Siri, “How many calories are in a kiwi?” She came back with 46 calories along with a full chart of all the nutritional information for a kiwi.
Last week when I was doing research for my article iPhone and Surface: The moment Apple and Microsoft diverged, I got frustrated trying to find historical data on the market cap and revenue of Microsoft and Apple going back to 2007. In desperation (and half-jokingly) I asked Siri a question about Microsoft revenue in 2007 and surprisingly got an answer, based on data from Wolfram Alpha (which was also the source of the kiwi data). That eventually led me to Wolfram Alpha on the web (from my computer) to do a full lookup of the data, but the fact that Siri led me there was a big “ah ha” moment.
Siri can also help you find nearby physicians, lookup movie times, and pull up weather data when you ask questions like, “is it going to rain tomorrow?” Siri still has a hard time understanding normal speech at times and it’s limited by its access to freely available data sources like Google, Wolfram Alpha, and Yelp. But, Apple has shown us what’s possible with a much more approachable VUI than anything we’ve seen so far in the consumer market. Siri is almost like an IBM Watson for the masses.
One of the important things to notice about Siri is how it disintermediates search results pages in general and Google specifically. Instead of giving you a page of possibilities to choose from, Siri tries to give you a single authoritative answer to your question. Since Google makes all of its money by allowing advertisers to place their ads next to the items listed on the search results pages, it’s easy to see why Google Chairman Eric Schmidt is talking about Siri as a competitive threat.

The next step

Now that Apple has opened the door to a natural language VUI and demonstrated new possibilities, the game really begins. Google and Microsoft will undoubtedly take cues from Siri and bring similar functionality to Android and Windows Phone, since both companies already have a lot of engineers working on voice technology. That means Apple is going to have to rapidly improve and innovate Siri if it wants to be a leader in VUI. Siri has two areas that need the most work: 1.) it needs to keep improving voice recognition, and 2.) it needs more data sources to feed Siri and integrate into its equation.
Currently, if Siri doesn’t have an answer to something, the fallback is to throw the question to a standard mobile web search. That’s not going to suffice for long – especially when you consider the level of integration that Google and Microsoft will be able to do since they both own search engines. Siri needs a web search that is tightly integrated into the service in the same way that Wolfram Alpha and Yelp are today.
That leaves Apple with three options: build, buy, or partner.

Build

Siri itself is already a bit of a search engine, and with all of the searches that are now happening through Siri and running through Apple’s servers, the company is amassing a treasure trove of data about the ways people are using voice search. Plus, all of the Siri data is tied to specific users and that will give Apple an excellent opportunity to do personalized search in the future.
Last year at the D8 conference when Steve Jobs was asked about Apple buying Siri and going into the search business he said, “They’re not a search company. They’re an AI company. We have no plans to go into the search business. We don’t care about it — other people do it well.”
While Jobs has famously denied lots of things that Apple eventually went on to do, it’s hard to see Apple building its own web search engine from scratch based around the core team it acquired from Siri. That would take years and lot of resources. Just look at how much money Microsoft has had to throw at building Bing, with only moderate success and no hope of turning a profit any time soon.

Buy

The faster on-ramp for Apple would be to buy one of the smaller players in web search, integrate it with the Siri team, and put most of its resources into customizing a VUI that feeds Siri. There are a few decent candidates that Apple could gobble up: Blekko, DuckDuckGo, Yippy, Dogpile, and even good old AskJeeves.
Apple has $80 billion in cash reserves so it has plenty of resources to buy any of these search engines. The best options would likely be DuckDuckGo and Blekko. Both of them already do some things better than Google, but don’t get much attention because they’re so small.

Partner

If Apple were to partner with another company in search it would have to be Google, Microsoft Bing, or Yahoo (which has mostly abandoned its own search for Bing). Google is an obvious “no” since it’s Apple’s archrival in mobile. Bing might look like it makes sense in the short term, since Microsoft has fashioned Bing as a “decision engine” rather than a search engine and that fits pretty well with what Siri is trying to accomplish.
But, Microsoft is destined to want to do something similar to Siri in Windows Phone and that will be enough to scare Apple away from a doing a deal with Microsoft.

Sanity check

With Siri, Apple has lowered the friction on search and turned it into a mellifluous experience. But, to take it to the next level, Apple is going to need much tighter integration with web search. Building a search engine would take too much time and there aren’t many good options for Apple to partner with in search, so the most likely scenario is that Apple will buy a smaller player and integrate it into Siri.
Siri clearly has tremendous future potential for Apple across its entire product line. By the end of 2013, I expect that we’ll see Siri on most iOS devices and Macintosh machines. Nick Bilton evenbelieves Siri is the revolutionary interface that Steve Jobs wanted to bring to television sets.
The bigger and more entertaining question is if Apple does jump into search with both feet, will the company freely release Siri on the Web and challenge Google directly? I doubt it, given Apple’s affinity for hardware/software integration, but it’s fun to consider, especially as we look at Apple’s new VUI as arguably the most important new development in search in the past decade.

Also read