samedi 26 juillet
April | Agenda du libre | Framasoft | Léa-Linux | Lolix | JeSuisLibre | Eyrolles | LinuxMag | Veni, Vidi, Libri | InLibroVeritas | LinuxGraphic
Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information
Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Entretiens :: Suivi :: RDF

: Eet passe en 1.0 alpha

Posté par Steven Le Roux (Jabber id, page perso, ). Modéré le 02 avril 2008.
Rasterman, le project leader d'Enlightenment, vient d'annoncer le passage au stade alpha de la bibliothèque Eet.

Cette bibliothèque, faisant partie des EFL[0] est dédiée à l'encodage/décodage et au stockage des données. Elle est écrite afin d'être très simple pour le programmeur, déchargeant une bonne partie des routines de lecture et d'écriture.

Elle peut par exemple stocker de multiples bouts de données dans un ficher unique à accès arbitraire et rapide, encoder ou décoder des images ou tout autre type de donnée. Les fichiers ainsi produits sont compacts et rapides d'accès tout en étant portable entre différentes architectures (exemple : il est possible de produire un fichier écrit sur une architecture 32bits x86 puis de l'utiliser sur une architecture 64bits PowerPC sans autre action que celle de le déplacer).

Eet est portable sur beaucoup d'architectures et de systèmes d'exploitation (actuellement porté sur GNU/Linux, *BSD et même windows grâce au travail de Vincent Torri entres autres) et fonctionne pleinement sur les systèmes embarqués comme sur les fermes de serveur multi core/CPU.

> Lire la dépêche (47 commentaires, moyenne: 3,7).  

Vous avez demandé le commentaire #919088.

Euh... Première page???

Posté par Zenitram (page perso, ) le 02/04/2008 à 09:39. (lien). Évalué à 7.

Corrigez-moi si je me trompe, mais la on ne parle pas de E17, mais d'une très petite API pour accéder à un fichier de données, de façon très simple.
Genre sqlite, mais en 100x moins puissant (il n'y a aucune gestion de base de données)
Je me demande pour quelle raison un version alpha d'une petit bout d'API a le droit à une "une"?
Le même traitement sera possible pour la version alpha d'une version de Gconf (qui fait bien plus que cette API...)? ou pour tout autre petit bout de projet sur lequel on aura mis le mot "API" pour 4 commandes qui se battent en duel?
Parce que API de ce style, il en sort des dizaines tous les jours (moins documentées, certes...)

  • [^]Re: Euh... Première page???

    Posté par √λιi () le 02/04/2008 à 10:08. (lien). Évalué à 10.

    Parce que API de ce style, il en sort des dizaines tous les jours (moins documentées, certes...)

    Des gens qui bossent aussi bien que Rasterman et sont équipe, y'en a pas beaucoup, donc non, des apis de ce style, il en sort certainement pas tous les jours.

    Avoir un lib de bonne qualité pour la gestion des configurations, pour par exemple remplacer le pratique mais lent, lourd et par forcément pertinent XML dans ~55kB tout en ayant une gestion du stockage de rasters compatibles multi-architecture, franchement ca mérite une annonce avant la version 1.0, rien que pour dire qu'elle existe et qu'il faut la tester.

    • [^]Re: Euh... Première page???

      Posté par Guillaume Knispel () le 03/04/2008 à 00:01. (lien). Évalué à 4.

      Honnêtement si tu fais pas de relationnel, je vois mal l'intérêt de stocker ta conf dans un fichier binaire... Faire chier le monde ?
      (et je suis pas fan du tout du XML non plus pour de la conf)

      Pour des chunks de binaires, c'est déjà plus intéressant.

      Concernant la qualité de la biblio, si quelqu'un a envie d'y contribuer je lui suggère amicalement de commencer par réduire la complexité de la fonction _eet_data_descriptor_decode(), qui est vraiment totalement inabordable.
      Heureusement elle fait un peu exception et la plupart du code semble assez bon.

      • [^]Re: Euh... Première page???

        Posté par cedric () le 03/04/2008 à 13:40. (lien). Évalué à 1.

        Effectivement eet_data.c a besoin d'une bonne refactorisation/nettoyage de code. C'est prevu, mais pour la prochaine version (car ca risque de casser beaucoup de chose comme changement). C'est d'ailleur un prerequis a l'ajout du support de nouveau type de donnees comme les tableaux et les unions.

    [^]Re: Euh... Première page???

    Posté par Clément David (Jabber id, page perso, ) le 02/04/2008 à 10:24. (lien). Évalué à 2.

    En fait je ne pense pas que la cible est la même, quand on voit les possibilités de sqlite on est quand même loin d'un simple gestion d'enregistrement, sauvegarde assisté pour une taille 7 fois plus grande.

    A voir sur cette page [http://www.sqlite.org/features.html], la connaissance de SQL (qui n'est pas commune dans le monde de l'embarqué) est forcément un pré-requis.

    --
    C# (sans runtime) + GObject = Vala

    [^]Re: Euh... Première page???

    Posté par Thomas DEBESSE (page perso, ) le 02/04/2008 à 10:55. (lien). Évalué à 10.

    En fait e17 est sensé sortir après le port de Duke Nukem Forever sous Hurd, alors lorsqu'une bibliothèque du projet sort en version alpha, c'est vraiment la fête !

    --
    † In te confirmátus sum ex útero : de ventre matris meæ tu es protéctor meus.

    [^]Re: Euh... Première page???

    Posté par Sébastien SAUVAGE (page perso, ) le 02/04/2008 à 11:43. (lien). Évalué à 8.

    Genre sqlite, mais en 100x moins puissant

    Oui justement j'y pensais.

    Au final SQLite est un excellent choix comme format de fichier pour n'importe quel ensemble de données non-trivial.

    Portable, compact, rapide, structuré, gère jusqu'à 2 To de données, supporte les données numériques, textuelles et binaires... une base SQLite a tous les avantages, surtout par rapport à des formats de fichier maison (pas de parseurs à écrire, etc.)
    (Et ne me lancez pas sur l'XML !)

    En prime, la gestion des transactions vous permet d'éviter la corruption des fichiers lors de l'écriture (ACID).

    La librairie est solide, accessible de pratiquement tous les langages et la license n'est vraiment pas chiante.

    Que des avantages. J'aime de plus en plus SQLite.

    • [^]Re: Euh... Première page???

      Posté par MilkaJinka () le 02/04/2008 à 12:13. (lien). Évalué à 1.

      De mon expérience, ça n'empêche pas que si la base de données est corrompue ça nous pourrit la vie. Amarok (qui utilise SQLite) m'a fait ça il n'y a pas longtemps, en plantant jusqu'a ce que je supprime purement et simplement la base de données.

      --
      Persiste.

      • [^]Re: Euh... Première page???

        Posté par alexissoft (Jabber id, page perso, ) le 02/04/2008 à 17:10. (lien). Évalué à 2.

        Et avec un XML ça n'arrive pas ?

        [^]Re: Euh... Première page???

        Posté par Sébastien SAUVAGE (page perso, ) le 03/04/2008 à 13:13. (lien). Évalué à 2.

        Peut-être une transaction mal fagotée ?

        Je n'ai jamais réussi à prendre SQLite en défaut (et c'est pas faute d'avoir essayé: base de 2 Go, extinction ou reset de l'ordinateur en plein milieu d'écritures, etc.)

        Firefox 2 utilise SQLite pour son système anti-phishing.
        Firefox 3, d'après ce que j'ai compris, utilisera massivement SQLite aussi pour les bookmarks, etc.

      [^]Re: Euh... Première page???

      Posté par dguihal () le 02/04/2008 à 16:53. (lien). Évalué à 4.

      le probleme c'est que les fichiers de conf ne sont plus alors lisibles simplement que par l'outil qui a servi a les creer, on ne peux plus rattraper une grosse boulette avec vim pas exemple

      • [^]Re: Euh... Première page???

        Posté par Gof (Jabber id, page perso, ) le 02/04/2008 à 18:37. (lien). Évalué à 3.

        le fichier binaire SQLite est lisible avec certains outils de gestions de base de donnée.
        Notemment avec l'exécutable 'sqlite3' qui permet de faire des requête ou des dump de la base de donnée lisible "simplement"

        --
        :-D !!!NOUVEAU!!!

        [^]Re: Euh... Première page???

        Posté par Sébastien SAUVAGE (page perso, ) le 03/04/2008 à 13:17. (lien). Évalué à 1.

        PS: J'ajoute que les fichiers SQLite sont auto-descriptifs (<troll>comme l'XML !</troll> (pas taper !)): Ils contiennent les requêtes SQL DDL (tables, etc.)

    [^]Re: Euh... Première page???

    Posté par boklm (page perso, ) le 02/04/2008 à 12:37. (lien). Évalué à 6.

    A quand une news à la une pour débattre de quel type de news mérite d'etre à la une ?

    • [^]Re: Euh... Première page???

      Posté par Bruno Michel (Jabber id, page perso, ) le 02/04/2008 à 13:12. (lien). Évalué à 2.

      Bof, il n' y en pas vraiment besoin : les lecteurs de LinuxFR en débâtent déjà assez souvent dans les autres dépêches.

    [^]Re: Euh... Première page???

    Posté par cedric () le 02/04/2008 à 16:17. (lien). Évalué à 1.

    L'objectif de EET n'est pas uniquement de fournir du stockage.

    Mais aussi de permettre de serialiser une structure de donnees pour l'envoyer a un autre programme sur le reseau ou via une IPC (et effectivement de l'enregistrer sur le disque).

    Pour la partie stockage, les fichiers en eux meme peuvent contenir aujourd'hui des donnees comme des images (avec ou sans canal alpha, compresse ou non), des data serialises ou des data binaires.

    Enfin eet est designe pour etre principalement utlise en lecture avec tres tres peu d'ecriture. C'est bien pour des fichiers de configuration, les data des programmes et ca n'a pas le meme usage que sqlite, ni les meme perfs. C'est d'ailleur utiliser par e17 pour ses themes et sa configuration. C'est une bibliotheque principale pour le projet Enlightenment qui meriterait d'etre utiliser pour plus de chose.

    Enfin si vraiment on veut comparer eet et sqlite, sur mon athlon 64, j'ai libeet.so == 72ko et libsqlite3.so == 443ko.

    • [^]Re: Euh... Première page???

      Posté par PasChauve PasOunet () le 02/04/2008 à 17:56. (lien). Évalué à 2.

      Enfin si vraiment on veut comparer eet et sqlite, sur mon athlon 64, j'ai libeet.so == 72ko et libsqlite3.so == 443ko.

      Je me demande si c'est vraiment valable comme comparaison , à l'époque où les disques durs faisaient 10mo Ok , mais maintenant le disque dur "etalon" quand tu l'achètes c'est 500Go ...
      ça n'a de sens que pour l'embarqué , et encore...

      • [^]Re: Euh... Première page???

        Posté par Sébastien Huss () le 02/04/2008 à 18:42. (lien). Évalué à 4.

        Enlightement vise les environnements enbarqués et avec peu de mémoire. Pourquoi a ton avis c'est E17 qui est utilisé avec YellowDog PS3 : la PS3 n'a que 256Mo de mémoire.
        Alors ouais, rien à faire coté disque, mais coté mémoire gagner 350Ko, c'est énorme pour l'embarqué.
        Et en terme de performance, je ne voudrais pas avoir à comparer SQLite avec EET. Parceque sans conteste possible EET est _très_ loin devant. Rasterman est un maniaque de la performance. Ceux qui se sont "amusé" à lire des bouts de code d'imlib2, comprendrons de quoi je parle. EET a été pensé "from scratch" avec de toutes petites machines dans la tête. Rappelons que l'objectif des EFL est d'être portable sur toute plateforme et en particulier les cellulaires et les palmtop. Il faut pas oublier qui est l'employeur de Rasterman actuellement.

        Moi, ce que j'attends c'est EVAS en 1.0 final. Parce que ce jour-là on pourra mettre à la poubelle CAIRO (la comparaison en performance des 2 est à pleurer...) Peut-être une idée pour GTK3 ?

        anyway, mes 2cents d'un utilisateur de kde4 :D

        • [^]Re: Euh... Première page???

          Posté par Raoul Hecky (page perso, ) le 02/04/2008 à 23:38. (lien). Évalué à 6.

          Evas et Cairo n'ont rien a voir, Cairo est un canvas vectoriel, Evas non. D'ou les différences de perfs.

          --
          ---
          http://www.calaos.fr

        [^]Re: Euh... Première page???

        Posté par cedric () le 02/04/2008 à 19:27. (lien). Évalué à 4.

        Juste comme ca, lorsque tu n'as que 20Mo de RAM, tu es bien content de pouvoir decider de n'utiliser que eet et de gagner au minimum 350ko (en realite un peu plus, car ca te fais des pages memoires de moins a manipuler pour l'OS).

        Et oui, il y a encore aujourd'hui des systemes qui n'ont quasiment pas de RAM, de CPU et une flash de petite taille. Alors autant rester efficace et utiliser des outils qui correspondent au besoin.

      [^]Re: Euh... Première page???

      Posté par Sébastien SAUVAGE (page perso, ) le 03/04/2008 à 13:14. (lien). Évalué à 1.

      Enfin eet est designe pour etre principalement utlise en lecture avec tres tres peu d'ecriture.

      Ah ok je comprend.

      (Ma remaque n'était aucunement faite dans l'intention de rabaisser eet.)

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.0922s (dont 0.0102 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.