Toujours en progression, mais je collectionne des infos sur le sujet en ce moment

Il s'agit cette fois d'utiliser des tables HTML comme une table de stockage SQL, interrogable "façon sql" en utilisant un plugin Jquery.
http://pivots.pivotallabs.com/users/nic ... e-gt-tags-

C'est assez intéressant, a correspond bien à la logique Jquery. Mais j'en vois pas encore trop l'utilité..

Bon, je progresse (pas facile, un tokenizer/parser/interpreter.. mais le côté stockage est déjà fixé), mais petit à petit..

J'ai trouvé ceci:
http://ajaxian.com/archives/jsonsql-jso ... -sql-style

qui permet d'interroger un object json façon sql. Je vois pas trop l'interêt, mais bon, tout ce qui propose un parseur SQL en JS m'intéresse en ce moment .

Par contre, ici, le gus utilise des conditions JS dans son where.. c'est certes plus facile à faire/implenter, mais j'aime pas trop.. c'est pas portable quoi..

pas simple ton problème berze, ceci dit c'est vrai que la question présente un interet certain. Pourquoi ne pas chercher du côté des plugins (active x et consort) pour voir s'il y'a une solution un peu uniformisable sur les différents navigateurs. Je me dit qu'un format de db comme sqlite serait parfait par exemple pour tes besoins.

ben, google gears
(qui incorpore sqlite, avec le module fts2 pour la recherche fulltext, enfin..)

Mais avec les supercookies de FF(5mo..) et le userdata de IE (1mo..), je garde espoir.

De l'autre côté,il y a la DB SQL de Html5, qui n'est supporté pour le moment que par webkit/Safari.. si seulement on pouvait déjà passer à Html5..

Je vais écrire un stresstest tiens, puisque la seule façon de vraiment connaître les limites des cookies est d'essayer.. (comme ici, et ici).

En tout cas, faudra s'attendre a voir des données disparaître

pas simple ton problème berze, ceci dit c'est vrai que la question présente un interet certain. Pourquoi ne pas chercher du côté des plugins (active x et consort) pour voir s'il y'a une solution un peu uniformisable sur les différents navigateurs. Je me dit qu'un format de db comme sqlite serait parfait par exemple pour tes besoins.

20 par domaine, 300 en tout, 4096 octets par cookie. Mais peut-être que ça varie (ce n'est jamais qu'un minimum conseillé, il me semble)

En effet, je n'ai plus le lien sous la main mais certains navigateurs (IE6 je pense) sont limités à 2000, et ce ne sont que des recommandations. En plus de ça, comme je disais le problème peut venir du serveur web en face, qui n'appréciera peut-être pas recevoir 20 * 4096 = 80 KiB d'headers lorsque le client demande une page. Enfin, tu verras bien sous ton IIS.

Par la compression, je doute que tu en profites, ou alors il te faudra créer ton propre algorithme. Pour compresser il faudrait pouvoir stocker en binaire, et comme les caractères spéciaux se retrouvent urlencoded, ils prennent trois fois plus de place. Ainsi, 2000 octets de données binaires pourraient dépasser la limite théorique de 4 KiB du cookie.

Pour la taille des cookies, j'avais déjà enquêté, la taille minimale supporté doit/est conseillé d'être de 4096 octets. Pour firefox, il y a ce qu'on appelle les "supercookies" (= dom.storage), par contre pour IE je ne savais pas, merci ^-^

Sinon, pour rappel sur les cookies:
20 par domaine, 300 en tout, 4096 octets par cookie. Mais peut-être que ça varie (ce n'est jamais qu'un minimum conseillé, il me semble).

Comme je tourne sous IIS, je verrais bien ce qu'il en pense des cookies..

La couche d'abstraction, en effet, j'y pensais (si je veux optimiser et utiliser les particularités des navigateurs du moins).

Il faut encore que j'étudie les moyens de compression et de serialisation.. jusque la j'utilise surtout json+base64, mais base64 allonge plus qu'autre chôse.. (logique, je sais, mais on y gagne en intégrité).

Pour les scripts existants, il me semble que javascript DB vise le respect de la norme SQL, tandis que trimquery se contente d'utiliser la syntaxe. Les deux me semblent trop lourds pour être vraiment viables.. dans mon cas, mais pour une grosse application bien lourde, ça doit être très fun.

Même si je ne connais rien des "Javascript DB" dont tu parles (manipuler/stocker les données du côté du client plutôt que du côté du serveur) sujet m'intéresse au plus haut point. J'irai jeter un coup d'œil sur les DB citées, mais en attendant voici ce que je sais, si ça peut être utile :

• attention à la limite de données par cookie. Même si on peut multiplier les cookies pour en stocker plus, il se peut qu'Apache s'étrangle en recevant plus de 8 KiB de cookies (combinés). Cette limite varie selon les installation/configuration d'Apache, je n'en sais pas plus (j'ai eu ce problème ici).
• DOMStorage sur Fx 2 permet de stocker des sortes gros cookies qui n'ont pas à être renvoyés vers le serveur.
• IE6+ a son propre truc, userData. Pas très pratique à utiliser, je crois l'avoir fait fonctionner sur IE7, pas testé sous IE6

Si les données ne sont qu'un historique, tu devrais pouvoir t'en sortir avec n'importe laquelle de ces techs. Mon conseil : fait une couche d'abstraction pour différentier le moteur de stockage et l'application.

Ah par contre, si tu fais une db, il faut qu'elle supporte le langage SQL, et avec transactions, clés étrangères, et triggers, sinon c'est pas drôle

tout doux tout doux.. faut que ça reste "light".. je vise l'implentation minimale.. (pour le surplus, javascriptDB ou trimquery le font déjà assez bien)

en tout cas, pour le début.. après, on verra.

C'est pas très très important (pas assez pour justifier l'espace sur le serveur), le serveur est assez petit, et je préfère économiser la bande passente pour les données ajax qui transitent.. d'autant que ça risque de générer pas mal de données, de traitement, et puis, c'est pas fun.

Coder une mini-DB côté client basé sur les cookies par contre, ça, c'est fun
(et comme je fais ce que je veux, et que je ne dois convaincre personne, je peux le faire)

L'idée se concrétise peu à peu, je crois que c'est ce que je vais faire.. au pire, ça foire, et au mieux, je l'hébergerais quelque part.

Ah ok

ben go pour une étude approfondie sur les habitudes d'utilisation en matière de nettoyage de cache et des cookies, et en fonction y'a plus qu'à coder le truc rigolo

Ah par contre, si tu fais une db, il faut qu'elle supporte le langage SQL, et avec transactions, clés étrangères, et triggers, sinon c'est pas drôle

C'est pas très très important (pas assez pour justifier l'espace sur le serveur), le serveur est assez petit, et je préfère économiser la bande passente pour les données ajax qui transitent.. d'autant que ça risque de générer pas mal de données, de traitement, et puis, c'est pas fun.

Coder une mini-DB côté client basé sur les cookies par contre, ça, c'est fun
(et comme je fais ce que je veux, et que je ne dois convaincre personne, je peux le faire)

L'idée se concrétise peu à peu, je crois que c'est ce que je vais faire.. au pire, ça foire, et au mieux, je l'hébergerais quelque part.

pourquoi vouloir autant limiter l'accès au serveur? c'est étrange. Je n'ai pas en tête de solution durable (les cookies et le cache navigateur sont deux espaces de stockages en js mais pas durables) pour faire de la db en js, en revanche faire de la session persistante côté serveur ca serait vachement plus simple

Dans la catégorie cookie DB, je viens de tomber sur ceci:
http://www.jsgoodis.com/jsdocs/ROLO.cookieDB.html

Je me demande si c'est bon comme truc.. je vous tiens au courant.

edit: bwah, c'est juste un tableau, mais directement enregistré dans un cookie.. pff..

Salut à tous.

Étant dans le développement d'applications web, je suis confronté à un choix.

J'ai, en ce moment, une application assez lourde côté client (d'ailleurs, elle réside complètement chez le client, il n'y a que des transferts de données asynchrones), qui permet de consulter une grosse arborescence, avec contenu associé aux noeuds, ainsi que d'effectuer des recherches.

Il y a surtout un historique de toutes les actions récentes (limité à 15..). Il y a un vif intérêt pour cet historique, et je me dis que je l'améliorerais bien, avec fonction de tri, de classification, etc.. Or, je suis déjà à la taille limite pour le cookie (4ko).

Mon idée est d'utiliser la db de google gears, mais ça suppose une installation côté client, que beaucoup risquent de ne pas faire.

Une option, une alternative, à google gears est une DB javascript (tel que javascriptDB, TrimQuery ou encore Taffy), que je pourrais utiliser si absence de G-G (dans ce cas la durée de vie de l'historique ne sera que celui de la session..).

Je ne veux surtout pas stocker les données côté serveur. J'ai donc 3 solutions:

- utiliser G-G, et tant pis pour les autres.
- utiliser G-G et une DB javascript (dans ce cas, j'espère que la syntaxe est la même, comme ça, c'est facile.. et tant pis pour la durée de vie.)
- N'utiliser que DB javascript et mettre en place un super-algo de sérialisation et de fragmentation pour enregistrer la DB dans des cookies...

J'aime particulièrement la dernière solution, mais j'ai un peu les boules pour le surpoids engendré pour le client.. (d'autant qu'il faudrait la mettre a jour à chaque modification..)

En même temps, je pourrais m'occuper à faire unet DB JS la plus légère possible (avec une syntaxe très limitée), utilisant directement les cookies, puisque le besoin que j'en ais est assez limité..

vous en pensez quoi ? (s'il y a quelque chôse à en penser..)