Ok, il faut qu'on redirige daemon_log_file vers stdout ou un endroit collecté par les logs docker.
Les images sont déjà factorisées, la seule chose que l'on télécharge en double, c'est la distribution pour solr car l'image Docker utilisée est une branche différente du reste qui utilise phusion baseimage (une bonne chose).
De toute façon, notre objectif à court terme est de tout stabiliser pour sortir une version 1.0 en mai 2015.
On va regarder les différents points. Quelques éléments de réponse pour commencer :
il y a une commande docker logs [container_name] qui est à utiliser car ensuite c'est intégré avec des plateformes complètes type kubernetes
IMAP : oui. Le but est d'écrire un serveur IMAP qui soit client des API PEPS. Par exemple en partant de Hoodiecrow pour rester en Node.js ou alors un backend pour dovecot.
solr : oui, il y a plusieurs problèmes avec solr, qui en plus consomme une partie non-négligeable des ressources. Nous envisageons de changer pour bleve.
"only admin", effectivement il reste un peu de travail (idem sur le provisioning, complexité du mot de passe, etc.)
write above/ordre de tri : oui, il faut rajouter des options dans les préférences utilisateur (par contre, on va probablement garder les choix par défaut comme gmail)
configuration SMTP : il suffit de modifier smtpin/config/smtp.ini et smtpout/config/smtp.ini. Par défaut, on peut mieux faire sur l'antispam, pull request bienvenu :)
Et comme indiqué dans un autre commentaire, nous allons effectivement partir sur une licence libre AGPL ! Attendez-vous à une dépêche bientôt pour le lancement :)
Pour information, nous sommes en phase de commercialisation avancée avec plusieurs grands comptes et les mentalités ont bien changé et heureusement : le logiciel libre est désormais un point qui rassure.
A la base, nous voulions une implémentation client donc JS. Nous avons regardé openpgpjs et trouvé le code un peu long pour être facilement auditable. Nous avons à la place implémenté une crypto applicative sur la base de tweetnacl-js.
Au passage, PEPS sera distribué selon une licence libre.
Parce que Node est un très bon choix pour le serveur applicatif, les interfaces REST.
Mais dans un produit un peu complexe comme PEPS, il faut de toute façon des technologies différentes car chacune a ses forces/faiblesses.
Et pour revenir sur Docker, cela va au-delà de la bonne configuration des composants pris séparément. En faisant make build run, on a par défaut une configuration correcte de l'interconnection, des ports, des règles de firewall. Alors oui, il y a (surtout ici) des gens qui savent faire seuls et qui sont aussi à même de changer ce qu'ils veulent, mais pour les autres par défaut ça marche.
Mais on ne peut pas "tout" faire en Node.js.
Par exemple, il n'y a aucun moteur d'indexation en Node.js, que des bindings vers des outils écrits en Java/C/C++/Go (récent, pour bleve) et qu'il faut déployer de toute façon. Et il n'y a pas mieux que Docker pour standardiser un déploiement.
Pour les fichiers, PEPS inclut une plateforme centralisée équivalente à Dropbox/Google Drive et qui ne repose pas sur des protocoles P2P. On ne cherche pas du tout à concurrencer BitTorrent Sync ou des équivalents libres.
Un point qui moi me chagrine : le commentaire sur Opa. Comme indiqué dans la discussion, nous sommes les auteurs d'Opa, qui est une solution libre. Je peux comprendre que tout le monde ne veut pas coder en Opa, mais reprocher aux auteurs d'une solution libre, que l'on maîtrise donc parfaitement et que l'on sait exploiter au mieux pour bien écrire un logiciel je ne comprends pas.
Ouvrons donc le débat (sachant que PEPS se veut une solution de communication professionnelle, pas forcément B2C) :
Commençons par le plus simple : les labels sont gérés par PEPS. C'est même une des fonctionnalités les plus développées, puisque nous avons des labels privés (comme Gmail), des labels partagés (par exemple un label peut être proposé par l'expéditeur) ainsi qu'un mécanisme de classification des messages basé sur les labels (gestion du besoin d'en connaître, fonctionnalité très B2B). Ce dernier inclut tout le champ de produits complémentaires de messagerie comme "Titus".
Minimum syndical de 1998 : justement, en commençant PEPS fin 2010 (il y a déjà 4 ans, développé à la base pour un grand compte français) le but était de partir sur des bases neuves et pas se limiter avec de l'existant. Du coup, tout le coeur de PEPS est basé sur les API REST nouvelles, ce qui permet plein de nouvelles fonctionnalités qui n'ont pas été évoquées ici (statut réel d'envoi/lecture pour les messages internes, gestion des équipes, envoi de messages aux équipes pour gérer les fonctions de boîtes de délégation, de mailing list, etc.). Nous assumons tout à fait le fait de ne pas être une solution de messagerie "classique".
Par exemple, le serveur IMAP n'a pas été retenu dans la base. Il y a des API dans PEPS suffisantes pour écrire un serveur IMAP en tant que service externe, par exemple via un backend dovecot client des API . Pour moi, il était essentiel d'avoir une codebase propre et modulaire et je pense que nous y sommes arrivé.
-Pour XMPP : nous avons déjà développé une application de chat pour PEPS que nous n'avons pas encore distribuée (initialement dans le cadre d'un projet avec un autre grand compte français). XMPP n'est pas encore supporté, mais oui il le faudrait, nous allons en faire une priorité.
En l'état, oui—mais la licence actuelle est probablement temporaire.
Nous sommes justement en train de préparer notre lancement et envisageons plusieurs possibilités de licence et de modèle commercial :
- propriétaire : proche de la licence actuelle, gratuit jusqu'à une limite d'utilisateurs à définir, payant au delà ;
- CC : par exemple BY-NC-SA, avec une licence payante pour les organisations (entreprises et institutions publiques) ;
- open source, et libre : par exemple AGPL. Dans ce cas, nous commercialiserions support / maintenance en comptant sur le fait d'être les auteurs pour justifier l'expertise / valeur ajoutée.
Il est difficile de choisir. Le but est bien sûr de créer une structure rentable, qui nous permette de vivre et de développer le produit bien plus loin, tout en permettant la diffusion la plus large possible. Et si, à titre personnel, je suis pour la solution libre, c'est un risque qui reste tout de même à mesurer…
Si vous avez un avis / feedback sur des situations similaires, nous sommes preneurs !
Oui, il y a des alternatives c'est sûr.
Par rapport à une solution de mail "pure", PEPS inclut directement les fonctionnalités de partage de fichiers/répertoires, ainsi qu'un chiffrement "transparent".
Le chiffrement des messages (pas tous, ceux qui ont une classification qui impose le chiffrement) utilisent PBKDF2+HMAC. Nous allons écrire un article à ce sujet, le but étant de chiffrer les messages sans connaissances particulières pour les utilisateurs.
Concernant le serveur IMAP, le but est d'écrire un plugin pour un serveur IMAP existant, par exemple dovecot. Cela reste à faire.
Au passage, RainLoop n'est pas libre non plus (CC BY-NC-SA) (ce qui est aussi une solution envisagée pour nous).
On est encore pre-launch, on est donc preneur de tout retour !
Pour FreeBSD, Docker semble supporter Jails (et pas seulement lxc) et tous les composants d'exécution sont aussi supportés, donc il me semble que cela est tout à fait faisable, en partant du repository actuel.
Concernant la licence, c'est une licence temporaire (il faut bien quelque chose) en attendant un choix. Open source ou pas, libre ou pas rien n'est arrêté. Pour info, nous sommes les auteurs d'Opa qui est utilisé pour développer PEPS et qui est libre (licence AGPL et MIT).
IMAP : serveur non, client oui (import de boîte IMAP)
webmail : oui
webdav: non
cardav : non
Pour les services manquants, le but est de les écrire sous forme de plugin (il y a déjà les API REST qu'utilise par exemple l'import de boîte IMAP qui est écrit en python).
La syntaxe précédente est toujours supportée et à ma connaissance stable.
Plus exactement, Opa accepte désormais une nouvelle syntaxe, qui a été demandée par la communauté car plus facile au premier abord pour les développeurs web.
Pourquoi est-ce que Opa serait instable ? Avez-vous essayé ?
Car la seconde phrase ressemble plus à FUD qu'autre chose.
Il faut des benchmarks par contre c'est vrai.
Réponse oubliée dans le feu de la discussion... et pourtant ce sont d'excellentes questions.
L'application jetleague.com est actuellement déployée sur 14 machines Amazon.
Le code actuellement disponible permet l'utilisation d'un serveur DB partagé derrière plusieurs serveurs web en front-end (topologie "en étoile"). Ce type d'architecture simple n'engendre pas de surcoût en terme de communication réseau.
Nous sommes en train de travailler sur les fonctions de gestion avancée des bases de données Opa (réplication, distribution, élasticité). Nous avons des prototypes qui marchent mais n'ont pas été mis en production et ne sont pas sur "master" : on devrait pusher ça dans les mois qui viennent.
Pour les topologies "en étoile", tout dépendra du degré d'utilisation (notamment en écriture) des données partagées. Normalement, cela correspond à pas mal d'usages -- et nous sommes également en train de travailler sur les optimisations de la db -- les performances devraient encore rapidement augmenter dans les mois qui viennent.
Pour l'instant, le code ne compile que sur AMD64 - il faut faire une passe sur le code d'Opa pour porter certains entiers en 64 bits (au lieu de natif) pour que ça marche bien (ou alors la taille de la base sera très limitée et les dates risquent d'être mal gérées.)
Volontaires bienvenus ;)
1) Faire le port 32 bits d'Opa : ce n'est pas compliqué mais il faut le faire proprement car tous les clés de la db sont des int natifs, et en 32 bit on a vite fait le tour... Il faut donc porter une partie du code pour utiliser les int64 explicitement.
2) Ensuite, le portage sur ARM devrait être faisable, car notre backend gère la plateforme en théorie, ce qui veut juste dire qu'il faudra passer du temps à débugger certaines choses.
Sur les deux sujets, les contributions de la communauté sont plus que bienvenues !
En particulier, si on n'a pas fait le port 32 bits, c'est qu'il nous a été peu demandé par les utilisateurs d'Opa avant notre passage en open source, mais c'est une demande que l'on voit émerger rapidement.
Tu es le bienvenu pour essayer Opa et faire une comparaison ;)
Les aspects Ajax et Web 2.0 sont gérés au coeur d'Opa puisque tous les échanges client/serveur sont automatisés avec un "slicer" qui sépare le code client du code serveur.
Et nous avons une proposition de meilleure syntaxe que nous allons ajouter à Opa. La syntaxe actuelle sera conservée en plus, même si elle n'est pas mise en avant et nous proposerons des outils de traduction de syntaxe (dans un sens ou dans l'autre).
Pour le second point, la quantité d'information que l'on connaît sur l'application en tant que telle nous ouvre la porte à énormément d'optimisations que l'on peut faire -- pour être très très bons en perf. Notamment sur un mode sans optimisation, par défaut ce qui semblait être le critère pour la "masse" des développeurs web.
Pour les concepts, nous avons bien fait du field testing avec des développeurs PHP ;) Et en fait le concept d'interface à la Opa et de "tout est récursif à toplevel" passe très bien. Ce qui manque, c'est un bon IDE pour mettre ce concept en valeur, mais là aussi les travaux sont en cours et on sortira quelque chose prochainement.
D'une certaine manière, beaucoup de personnes qui ont regardé Opa de près pensent que les deux "concurrents" d'Opa sont : Node.js et Scala+Lift.
Ce serait bien de construire un comparatif entre Opa, Node.js et Scala. A priori :
- le principal avantage de Node est de reposer sur un langage très connu
- le principal avantage de Scala est d'être compatible avec Java
- Opa et Scala sont bien meilleurs que Node en terme de détection d'erreur à la compilation et de qualité du code en général
- Opa est plus expressif que Node ou Scala
C'est difficile à expliquer rapidement car cela change de l'existant, mais Opa est une technologie qui inclut tous les aspects de la programmation web, y compris la db.
Sur un schéma différent de ce qui existe, puisqu'il n'y a pas en Opa de "moteur de db" à runtime.
A la place, le code d'un programme en Opa spécifie la nature des données qui sont stockées de manière persistante, les accès en lecture et en écriture à ces données.
Lors de la compilation, le compilateur génère du code compilé pour accéder et modifier ces données sur le disque. Toutes les requêtes spécifiées dans le code d'une application Opa sont donc compilées statiquement et utilisent une bibliothèque de graphes distribuées, spécifique à Opa.
D'une certaine façon, cette "base" appartient au monde NoSQL, dans la famille des bases de données de graphes distribuées.
[^] # Re: .
Posté par |-| . En réponse à la dépêche PEPS, nouvelle solution libre de messagerie et partage de fichiers. Évalué à 3.
Ok, il faut qu'on redirige
daemon_log_filevers stdout ou un endroit collecté par les logs docker.Les images sont déjà factorisées, la seule chose que l'on télécharge en double, c'est la distribution pour solr car l'image Docker utilisée est une branche différente du reste qui utilise phusion baseimage (une bonne chose).
De toute façon, notre objectif à court terme est de tout stabiliser pour sortir une version 1.0 en mai 2015.
[^] # Re: .
Posté par |-| . En réponse à la dépêche PEPS, nouvelle solution libre de messagerie et partage de fichiers. Évalué à 4.
Merci pour le super feedback !
On va regarder les différents points. Quelques éléments de réponse pour commencer :
docker logs [container_name]qui est à utiliser car ensuite c'est intégré avec des plateformes complètes type kubernetessmtpin/config/smtp.inietsmtpout/config/smtp.ini. Par défaut, on peut mieux faire sur l'antispam, pull request bienvenu :)[^] # Re: Doublon ?
Posté par |-| . En réponse à la dépêche PEPS, nouvelle solution libre de messagerie et partage de fichiers. Évalué à 9.
Et surtout il y a une différence importante entre la dépêche et mon précédent journal : cétaipalibre !
[^] # Re: PEPS is free for up to 30 user accounts.
Posté par |-| . En réponse au journal PEPS : Une nouvelle solution de messagerie (et plus) pour Linux. Évalué à 4.
Merci pour les retours.
Et comme indiqué dans un autre commentaire, nous allons effectivement partir sur une licence libre AGPL ! Attendez-vous à une dépêche bientôt pour le lancement :)
Pour information, nous sommes en phase de commercialisation avancée avec plusieurs grands comptes et les mentalités ont bien changé et heureusement : le logiciel libre est désormais un point qui rassure.
[^] # Re: RainLoop c'est bien et c'est stable
Posté par |-| . En réponse au journal PEPS : Une nouvelle solution de messagerie (et plus) pour Linux. Évalué à 3.
Bonne nouvelle : PEPS sera distribué selon une licence libre.
Du coup, tout le monde pourra comparer sur pièce !
[^] # Re: RainLoop c'est bien et c'est stable
Posté par |-| . En réponse au journal PEPS : Une nouvelle solution de messagerie (et plus) pour Linux. Évalué à 3.
A la base, nous voulions une implémentation client donc JS. Nous avons regardé openpgpjs et trouvé le code un peu long pour être facilement auditable. Nous avons à la place implémenté une crypto applicative sur la base de tweetnacl-js.
Au passage, PEPS sera distribué selon une licence libre.
[^] # Re: de la simplicité, des coquelicots et de mon avis.
Posté par |-| . En réponse au journal PEPS : Une nouvelle solution de messagerie (et plus) pour Linux. Évalué à 2.
Parce que Node est un très bon choix pour le serveur applicatif, les interfaces REST.
Mais dans un produit un peu complexe comme PEPS, il faut de toute façon des technologies différentes car chacune a ses forces/faiblesses.
Et pour revenir sur Docker, cela va au-delà de la bonne configuration des composants pris séparément. En faisant make build run, on a par défaut une configuration correcte de l'interconnection, des ports, des règles de firewall. Alors oui, il y a (surtout ici) des gens qui savent faire seuls et qui sont aussi à même de changer ce qu'ils veulent, mais pour les autres par défaut ça marche.
[^] # Re: de la simplicité, des coquelicots et de mon avis.
Posté par |-| . En réponse au journal PEPS : Une nouvelle solution de messagerie (et plus) pour Linux. Évalué à 5.
Mais on ne peut pas "tout" faire en Node.js.
Par exemple, il n'y a aucun moteur d'indexation en Node.js, que des bindings vers des outils écrits en Java/C/C++/Go (récent, pour bleve) et qu'il faut déployer de toute façon. Et il n'y a pas mieux que Docker pour standardiser un déploiement.
Pour les fichiers, PEPS inclut une plateforme centralisée équivalente à Dropbox/Google Drive et qui ne repose pas sur des protocoles P2P. On ne cherche pas du tout à concurrencer BitTorrent Sync ou des équivalents libres.
Un point qui moi me chagrine : le commentaire sur Opa. Comme indiqué dans la discussion, nous sommes les auteurs d'Opa, qui est une solution libre. Je peux comprendre que tout le monde ne veut pas coder en Opa, mais reprocher aux auteurs d'une solution libre, que l'on maîtrise donc parfaitement et que l'on sait exploiter au mieux pour bien écrire un logiciel je ne comprends pas.
[^] # Re: Retour volontairement agressif pour aller à l'essentiel et provoquer le débat...
Posté par |-| . En réponse au journal PEPS : Une nouvelle solution de messagerie (et plus) pour Linux. Évalué à 7.
Ouvrons donc le débat (sachant que PEPS se veut une solution de communication professionnelle, pas forcément B2C) :
Commençons par le plus simple : les labels sont gérés par PEPS. C'est même une des fonctionnalités les plus développées, puisque nous avons des labels privés (comme Gmail), des labels partagés (par exemple un label peut être proposé par l'expéditeur) ainsi qu'un mécanisme de classification des messages basé sur les labels (gestion du besoin d'en connaître, fonctionnalité très B2B). Ce dernier inclut tout le champ de produits complémentaires de messagerie comme "Titus".
Minimum syndical de 1998 : justement, en commençant PEPS fin 2010 (il y a déjà 4 ans, développé à la base pour un grand compte français) le but était de partir sur des bases neuves et pas se limiter avec de l'existant. Du coup, tout le coeur de PEPS est basé sur les API REST nouvelles, ce qui permet plein de nouvelles fonctionnalités qui n'ont pas été évoquées ici (statut réel d'envoi/lecture pour les messages internes, gestion des équipes, envoi de messages aux équipes pour gérer les fonctions de boîtes de délégation, de mailing list, etc.). Nous assumons tout à fait le fait de ne pas être une solution de messagerie "classique".
Par exemple, le serveur IMAP n'a pas été retenu dans la base. Il y a des API dans PEPS suffisantes pour écrire un serveur IMAP en tant que service externe, par exemple via un backend dovecot client des API . Pour moi, il était essentiel d'avoir une codebase propre et modulaire et je pense que nous y sommes arrivé.
-Pour XMPP : nous avons déjà développé une application de chat pour PEPS que nous n'avons pas encore distribuée (initialement dans le cadre d'un projet avec un autre grand compte français). XMPP n'est pas encore supporté, mais oui il le faudrait, nous allons en faire une priorité.
[^] # Re: PEPS is free for up to 30 user accounts.
Posté par |-| . En réponse au journal PEPS : Une nouvelle solution de messagerie (et plus) pour Linux. Évalué à 4.
En l'état, oui—mais la licence actuelle est probablement temporaire.
Nous sommes justement en train de préparer notre lancement et envisageons plusieurs possibilités de licence et de modèle commercial :
- propriétaire : proche de la licence actuelle, gratuit jusqu'à une limite d'utilisateurs à définir, payant au delà ;
- CC : par exemple BY-NC-SA, avec une licence payante pour les organisations (entreprises et institutions publiques) ;
- open source, et libre : par exemple AGPL. Dans ce cas, nous commercialiserions support / maintenance en comptant sur le fait d'être les auteurs pour justifier l'expertise / valeur ajoutée.
Il est difficile de choisir. Le but est bien sûr de créer une structure rentable, qui nous permette de vivre et de développer le produit bien plus loin, tout en permettant la diffusion la plus large possible. Et si, à titre personnel, je suis pour la solution libre, c'est un risque qui reste tout de même à mesurer…
Si vous avez un avis / feedback sur des situations similaires, nous sommes preneurs !
[^] # Re: RainLoop c'est bien et c'est stable
Posté par |-| . En réponse au journal PEPS : Une nouvelle solution de messagerie (et plus) pour Linux. Évalué à 3.
Oui, il y a des alternatives c'est sûr.
Par rapport à une solution de mail "pure", PEPS inclut directement les fonctionnalités de partage de fichiers/répertoires, ainsi qu'un chiffrement "transparent".
Le chiffrement des messages (pas tous, ceux qui ont une classification qui impose le chiffrement) utilisent PBKDF2+HMAC. Nous allons écrire un article à ce sujet, le but étant de chiffrer les messages sans connaissances particulières pour les utilisateurs.
Concernant le serveur IMAP, le but est d'écrire un plugin pour un serveur IMAP existant, par exemple dovecot. Cela reste à faire.
Au passage, RainLoop n'est pas libre non plus (CC BY-NC-SA) (ce qui est aussi une solution envisagée pour nous).
[^] # Re: Docker c'est bien mais...
Posté par |-| . En réponse au journal PEPS : Une nouvelle solution de messagerie (et plus) pour Linux. Évalué à 3.
On est encore pre-launch, on est donc preneur de tout retour !
Pour FreeBSD, Docker semble supporter Jails (et pas seulement lxc) et tous les composants d'exécution sont aussi supportés, donc il me semble que cela est tout à fait faisable, en partant du repository actuel.
Concernant la licence, c'est une licence temporaire (il faut bien quelque chose) en attendant un choix. Open source ou pas, libre ou pas rien n'est arrêté. Pour info, nous sommes les auteurs d'Opa qui est utilisé pour développer PEPS et qui est libre (licence AGPL et MIT).
[^] # Re: Serveur de courrier
Posté par |-| . En réponse au journal PEPS : Une nouvelle solution de messagerie (et plus) pour Linux. Évalué à 5.
Il n'y a pas encore tout…
Pour les services manquants, le but est de les écrire sous forme de plugin (il y a déjà les API REST qu'utilise par exemple l'import de boîte IMAP qui est écrit en python).
[^] # Re: Scrunieunieu et grumgrum
Posté par |-| . En réponse au journal Création d'un web-service de type REST en Opa. Évalué à 3.
Node.js (et donc Opa), c'est du JS côté serveur!
[^] # Re: Engouement
Posté par |-| . En réponse à la dépêche Opa se rapproche de Javascript. Évalué à 4.
La syntaxe précédente est toujours supportée et à ma connaissance stable.
Plus exactement, Opa accepte désormais une nouvelle syntaxe, qui a été demandée par la communauté car plus facile au premier abord pour les développeurs web.
[^] # Re: Engouement
Posté par |-| . En réponse à la dépêche Opa se rapproche de Javascript. Évalué à 1.
Pourquoi est-ce que Opa serait instable ? Avez-vous essayé ?
Car la seconde phrase ressemble plus à FUD qu'autre chose.
Il faut des benchmarks par contre c'est vrai.
[^] # Re: Brrr…
Posté par |-| . En réponse à la dépêche Ouverture du concours Opa Developer Challenge. Évalué à 0.
Ceci dit, cela est probablement une bonne occasion pour le futur heureux gagnant de contribuer à 3dbrew: http://3dbrew.org/wiki/Main_Page
[^] # Re: Support des navigateurs
Posté par |-| . En réponse à la dépêche Opa, un nouveau langage pour le développement d’applications Web. Évalué à 4.
Réponse oubliée dans le feu de la discussion... et pourtant ce sont d'excellentes questions.
L'application jetleague.com est actuellement déployée sur 14 machines Amazon.
Le code actuellement disponible permet l'utilisation d'un serveur DB partagé derrière plusieurs serveurs web en front-end (topologie "en étoile"). Ce type d'architecture simple n'engendre pas de surcoût en terme de communication réseau.
Nous sommes en train de travailler sur les fonctions de gestion avancée des bases de données Opa (réplication, distribution, élasticité). Nous avons des prototypes qui marchent mais n'ont pas été mis en production et ne sont pas sur "master" : on devrait pusher ça dans les mois qui viennent.
Pour les topologies "en étoile", tout dépendra du degré d'utilisation (notamment en écriture) des données partagées. Normalement, cela correspond à pas mal d'usages -- et nous sommes également en train de travailler sur les optimisations de la db -- les performances devraient encore rapidement augmenter dans les mois qui viennent.
[^] # Re: j'ai pas pu tester
Posté par |-| . En réponse à la dépêche Opa, un nouveau langage pour le développement d’applications Web. Évalué à 2.
Pour l'instant, le code ne compile que sur AMD64 - il faut faire une passe sur le code d'Opa pour porter certains entiers en 64 bits (au lieu de natif) pour que ça marche bien (ou alors la taille de la base sera très limitée et les dates risquent d'être mal gérées.)
Volontaires bienvenus ;)
[^] # Re: Questions
Posté par |-| . En réponse à la dépêche Opa, un nouveau langage pour le développement d’applications Web. Évalué à 1.
Concernant ARM, il faut :
1) Faire le port 32 bits d'Opa : ce n'est pas compliqué mais il faut le faire proprement car tous les clés de la db sont des int natifs, et en 32 bit on a vite fait le tour... Il faut donc porter une partie du code pour utiliser les int64 explicitement.
2) Ensuite, le portage sur ARM devrait être faisable, car notre backend gère la plateforme en théorie, ce qui veut juste dire qu'il faudra passer du temps à débugger certaines choses.
Sur les deux sujets, les contributions de la communauté sont plus que bienvenues !
En particulier, si on n'a pas fait le port 32 bits, c'est qu'il nous a été peu demandé par les utilisateurs d'Opa avant notre passage en open source, mais c'est une demande que l'on voit émerger rapidement.
[^] # Re: Questions
Posté par |-| . En réponse à la dépêche Opa, un nouveau langage pour le développement d’applications Web. Évalué à 1.
Tu es le bienvenu pour essayer Opa et faire une comparaison ;)
Les aspects Ajax et Web 2.0 sont gérés au coeur d'Opa puisque tous les échanges client/serveur sont automatisés avec un "slicer" qui sépare le code client du code serveur.
[^] # Re: "The Right Thing" vs "Worst is Better"
Posté par |-| . En réponse à la dépêche Opa, un nouveau langage pour le développement d’applications Web. Évalué à 3.
Merci pour cette excellente analyse.
Je partage notamment tout à fait ce que tu dis sur le rôle de la syntaxe. Nous avons récupéré énormément de feedback à ce sujet lors de discussion précédentes, cf. http://dutherenverseauborddelatable.wordpress.com/2011/05/30/crowdsourcing-the-syntax/
Et nous avons une proposition de meilleure syntaxe que nous allons ajouter à Opa. La syntaxe actuelle sera conservée en plus, même si elle n'est pas mise en avant et nous proposerons des outils de traduction de syntaxe (dans un sens ou dans l'autre).
Pour le second point, la quantité d'information que l'on connaît sur l'application en tant que telle nous ouvre la porte à énormément d'optimisations que l'on peut faire -- pour être très très bons en perf. Notamment sur un mode sans optimisation, par défaut ce qui semblait être le critère pour la "masse" des développeurs web.
Pour les concepts, nous avons bien fait du field testing avec des développeurs PHP ;) Et en fait le concept d'interface à la Opa et de "tout est récursif à toplevel" passe très bien. Ce qui manque, c'est un bon IDE pour mettre ce concept en valeur, mais là aussi les travaux sont en cours et on sortira quelque chose prochainement.
[^] # Re: Node.js
Posté par |-| . En réponse à la dépêche Opa, un nouveau langage pour le développement d’applications Web. Évalué à 2.
D'une certaine manière, beaucoup de personnes qui ont regardé Opa de près pensent que les deux "concurrents" d'Opa sont : Node.js et Scala+Lift.
Ce serait bien de construire un comparatif entre Opa, Node.js et Scala. A priori :
- le principal avantage de Node est de reposer sur un langage très connu
- le principal avantage de Scala est d'être compatible avec Java
- Opa et Scala sont bien meilleurs que Node en terme de détection d'erreur à la compilation et de qualité du code en général
- Opa est plus expressif que Node ou Scala
[^] # Re: lisibilité
Posté par |-| . En réponse à la dépêche Opa, un nouveau langage pour le développement d’applications Web. Évalué à 2.
C'est un nouveau langage (avec un nouveau système de types notamment), implanté en OCaml.
[^] # Re: Base de données
Posté par |-| . En réponse à la dépêche Opa, un nouveau langage pour le développement d’applications Web. Évalué à 3.
Très bonne question.
C'est difficile à expliquer rapidement car cela change de l'existant, mais Opa est une technologie qui inclut tous les aspects de la programmation web, y compris la db.
Sur un schéma différent de ce qui existe, puisqu'il n'y a pas en Opa de "moteur de db" à runtime.
A la place, le code d'un programme en Opa spécifie la nature des données qui sont stockées de manière persistante, les accès en lecture et en écriture à ces données.
Lors de la compilation, le compilateur génère du code compilé pour accéder et modifier ces données sur le disque. Toutes les requêtes spécifiées dans le code d'une application Opa sont donc compilées statiquement et utilisent une bibliothèque de graphes distribuées, spécifique à Opa.
D'une certaine façon, cette "base" appartient au monde NoSQL, dans la famille des bases de données de graphes distribuées.