>le plugin flash vient avec le player standalone, donc oui, tu peux lancer du flash en dehors du navigateur.
J'ai oublié de préciser : dans un navigateur "graphique". Ce que je voulais dire par là, c'est que le contenu web est accessible par d'autres moyens qu'un navigateur graphique (moteur d'indexation par exemple, lecteur vocaux etc). Ce n'est pas le cas de Flash... Il faut obligatoirement un lecteur flash, ou alors se faire un analyseur de blob flash, mais c'est pas évident à faire, alors que parser du HTML, c'est du texte, donc au pire, quelques regexp pour accéder à des informations spécifiques peuvent suffire, sans compter les nombreuses implémentation DOM.
Pour ce qui est de la technique, je suis bien d'accord que flash rend certains services aux développeurs, je l'ai même signalé à la fin de mon commentaire. Mais le débat n'est pas là. Le débat portait sur le fait que Flash n'est PAS une technologie "web". C'est une technologie pour faire des applications. Point. Mais ce n'est pas web, car ça ne suit pas la philosophie du Web. Ça ne comporte pas les concepts qui font le Web.
>SVG ca fait des annees qu'on nous bassine avec, et ca n'a toujours rien donne,
Y a pourtant des implémentations dans les principaux moteurs, il y avait un plugin Adobe etc... Certes, elles ne sont pas complète, mais ça fonctionne quand même, et ça s'améliore. La non-expansion de SVG est surtout dû à IE. Et puis aussi au rouleau marketing d'Adobe avec son flash.
>et personne n'a prit la peine de developper des outils autour.
Ça c'est complètement faux. Adobe propose des outils pour faire du SVG par exemple. Et Inkscape, l'éditeur SVG libre, très complet je trouve, c'est du vent ?
>Pour revenir a la source du probleme, concernant ton laius sur les brevets, j'aimerais bien que tu me prouves formellement que ogg/theora est libre de tout brevet.
Il y a des suspicions, mais personne n'en n'est sûr, c'est l'une des raisons pour lesquelles la recommandation du format ogg a été retirée de la spec HTML5. Mais as-tu un format video plus ouvert et plus "libre" de tout brevet, que Ogg ?
En tout cas, Mozilla n'hésite pas à l'inclure dans Firefox. C'est donc qu'il ne doit pas y avoir tant de risque que ça.
>les libristes se branlent la nouille sur une balise web qui va juste servir à normaliser l'accès... à des contenus multimédias encodés dans des codecs proprio. Super.
ET ALORS ? C'est déjà un premier pas, qu'il y ait au moins une spécification pour lire de la vidéo. C'est déjà un bon départ, un socle, pour promouvoir l'utilisation de format libre de video. Tu crois que c'est avec Flash ou Silverlight qu'un jour tout le monde utilisera Ogg Theora ou autre format libre ?
Si on commence pas par un bout, par cette balise video, aucune chance que des formats videos ouverts soient intensivement utilisés sur le web.
>Parcqu'il n'y a pas beaucoup de raison technique de l'utiliser : moins bonne qualité, peu implémenté par les softs et le hard.
Pour la qualité, c'est un bon troll des familles, d'une part. Et d'autre part, pour ce qui est de l'implémentation, on en reparlera dans un an (voir moins), quand Firefox 3.1 aura remplacé la majeure partie des installations de Firefox 3.0 actuelles. Un support natif de Ogg Theora sur 30% des machines d'internautes, ça ne sera pas significatif selon toi ?? Hein ?? (et je compte pas les installations de webkit et opera) Ce sera moins bien que le 1% actuel ? (au pif, mais je dois pas être loin, sinon très optimiste sur ce chiffre)
Et tu va encore me dire, "sera peu utilisé sur les sites web, bla bla bla". Oui mais si on offre absolument rien aux développeurs web pour qu'il puisse utiliser un format ouvert, là encore, aucune chance que ces formats se propagent.
Bref, cette balise video c'est une opportunité pour la propagation des formats ouverts. C'est sûr, au debut, tout le monde va pas se jeter sur ogg theora, mais au moins, il y aura dans les navigateurs plus de moyen de les utiliser qu'actuellement. Donc ça viendra.
Franchement, c'est dingue ton defaitisme. Parce que oui, c'est vraiment du defaitisme que tu nous fais là.
Alors oui, je suis un libriste "qui se branle la nouille" sur une balise web, parce que je vois en cette technologie une formidable opportunité pour promouvoir des formats ouverts et libres.
>Mais flash normalise le contenu,
je ne sais pas ce que tu appelle par "normalise", mais excuse moi, HTML5 est tout de ce qu'il y a de plus normalisé, et n'est de plus, pas un format contrôlé par une seule entreprise.
Le web, c'est un socle reposant sur des technologies ouvertes et accessibles, dans tous les sens des termes, et qui sont dans la lignée de la philosophie du concepteur du web, Tim Berners-Lee.
Silverlight et Flash, ce ne sont pas des technologies web. Pourquoi ? Pour faire vite :
- leurs specifications ont beau s'ouvrir, ça reste des spécifications propriétaires. Car ces spécifications restent dans les mains d'une même boite. Va donc toi, entreprise, ou expert, aller participer à leur élaboration. Ce n'est pas le cas des vrais technos web, dont les specs sont développés au sein d'un consortium, et ou chacun peut participer. Bref, la soit-disant "ouverture" de ces specs proprio, c'est de la poudre aux yeux. Et je ne parle pas des menaces juridiques de leur implémentation. Rien ne garanti que Adobe ou MS ne vont pas un jour tomber sur les auteurs d'une implémentation tierce (peu importe la raison), pour violation de Brevet, ou autre. Aucune chance que ça arrive avec les technologies web. Les spécifications normalisées au W3C sont librement implémentable et libre de tout brevet logiciel ou autre (ou en tout cas, les entreprises à l'origine de ces technos n'ont pas le droit de demander royalties ou de poursuivre juridiquement un implémenteur ou un utilisateur)
- les applis développés avec flash ou silverlight, ce sont des boites noires. Tu ne peux pas voir le code source. Avec les technologies web, si. Tu fais un view source dans ton navigateur, et tu as accès au code source. Instantanément. Tu peux donc apprendre, vérifier, comprendre comment la page web ou l'appli web fonctionne (au moins coté client). Combien de développeur web ont commencé en faisant un view source, au moins juste par curiosité ? À peu prés tous. Va donc faire ça avec un blob pour un plugin flash ou silverlight... Ça n'a l'air peut être rien pour toi, mais si le web s'était construit sur des technos aussi fermées pour l'utilisateur que le flash, eh bien le web n'existerait pas, et on serait probablement en train d'utiliser des "navigateurs" (si on peut appeler ça) spéciaux sur un reseau AOL ou MSN, tel que cela avait été imaginé par MS et AOL dans les années 90 pour "contrer" ce web merveilleux et ouvert tel qu'on le connait aujourd'hui. On serait donc enfermer dans un réseau dont on aurait aucun contrôle. Et avec Silverlight et Flash, ils tentent à nouveau de "contrôler" ce type de web fermé.
À propos de contrôle, les technologies web, par leur ouverture, permettent à l'utilisateur d'en contrôler le fonctionnement, ou tout au moins l'affichage. As-tu un jour pu faire un copier-coller de n'importe quel morceau de texte affiché par du flash ? As-tu pu un jour zoomer, changer les couleurs, sur du texte ou des dessins affichés par du flash ? As-tu pu un jour contrôler totalement l'affichage de ce que présente une appli flash ? As-tu pu utiliser une application flash en dehors d'un navigateur "classique" desktop ? As-tu pu afficher directement une "page" d'une application flash ? Assurément, toutes les réponses sont non. Par contre, pour les technologies web, si. Parce qu'elle le permettent, parce qu'elles sont conçus pour être accessible un maximum, pas forcément à ceux atteint d'un handicap, mais vraiment accessible à TOUT le monde et à TOUTE application. La preuve en est aussi le succés de greasemonkey, des bloqueurs de pubs, des moteurs de recherches, sans parler des possibilités pour l'utilisateur d'appliquer des feuilles de styles spécifiques à un site, de contrôler ce qui peut être fait ou non dans une page web (l'execution de code js, l'affichage des images etc). Bref, avec les vrais technologies web, l'utilisateur garde le contrôle du contenu. Avec Flash et Silverlight, pas du tout.
D'autres mots qui me viennent à l'esprit pour décrire le web : UNIVERSALITÉ, mais aussi LIENS HYPERTEXTES. Avec cette ouverture du code, ce degré d'accessibilité tant à l'information qu'au code source, tous ça est vraiment ce qui caractérise le web, qui a servi à l'expansion du web, et qui a fait son succès. Et ce n'est absolument pas des technos comme flash ou silverlight qui vont améliorer ces caractéristiques. Elles ne sont pas conçu pour.
Bref, ce n'est pas parce qu'on peut les utiliser dans un page web, et qu'elles sont peut-être "sexy" à utiliser pour les développeurs, que ce sont des technos dites "web". Pas dans le sens noble et original du terme "web". Ce sont des technos. Point. Mais pas web.
Ah ba c'est sûr, avec des types comme toi totalement défaitiste, et faisant plutôt la promotion de techno semi proprio, le format ogg va avoir du mal à percer... Heureusement que des gens comme Mozilla pensent autrement...
Au fait, toi qui pense que la balise video c'est du vent : wikipedia/wikimedia n'autorise que l'utilisation de video au format ogg. Nulle doute qu'ils vont utiliser cette balise video.
Ta video, elle s'affichera quoi qu'elle arrive. Si le navigateur ne connait pas la balise video, il saura l'afficher si il y a le plugin flash.
Avantage : à ceux qui auront un navigateur supportant la balise video, on pourra leur fournir par exemple une video de meilleure qualité. Sans compter une accessibilité autrement meilleur qu'un truc pourri en flash, et tout les avantages qu'apportent la balise video par rapport à object. http://ljouanneau.com/blog/post/2007/04/17/659-la-balise-video (ce billet date un peu, la recommandation vis à vis de ogg a été enlevée).
Pour ce qui est dans l'implémentation dans les navigateurs, sans nulle doute que les développeurs des navigateurs vont faire comme Mozilla, pour ne pas être "à la traine" : permettre de prendre en charge un maximum de formats video en s'appuyant sur ce que propose le système d'exploitation. Les internautes vont forcément préférer le navigateur qui leur permettra une meilleure "expérience utilisateur".
Bref, pour la compatibilité entre navigateur, je ne m'en fais pas du tout, ça va venir.
En tout cas, il est triste ton avis sur les standards du web. Mais bon, libre à toi de soutenir les technos semi-propriétaire de Microsoft ou Adobe...
Le navigateur peut faire appel au système pour lire la video (c'est ce que fera Firefox en passant par DirectMedia ou gStreamer, en plus du support natif ogg theora). Donc en theorie, toutes les videos seront lisibles. Suffira que l'utilisateur installe les codecs nécessaires (si ce n'est pas déjà fait).
>Oué bah en attendant pour faire du multimédia on a toujours rien :
mouai... donc la balise video et audio dans Firefox 3.1 (qui sort à la fin de l'année), dans Opera (et dans webkit, je sais plus), c'est du vent ? Firefox contient un backend ogg theora en standard, et d'autres backend vont arriver (directmedia, gstreamer etc).
Pour les animations, SMIL commence à pointer le bout de son nez chez webkit, opera et Firefox (ça fait parti du test acid3) et il existe déjà dans IE depuis quelques années (ou a existé, je ne sais plus, et est utilisé dans window media player). C'est pas du serieux ?
D'ici un an, on aura des implémentations SMIL et video dans quasi tout les navigateurs. Je crois qu'on peut attendre un peu, ou même commencer à utiliser ces technos.
Sans parler que Mozilla vient d'annoncer la création d'un projet d'outils pour développeur web, qui, on peut l'éspérer, tiendra compte des technos récentes incluses dans nos navigateurs préférés. http://labs.mozilla.com/2008/10/developer-tools-and-the-open(...)
Alors bon, les trucs à moitié libre, super verbeux (c'est vraiment cracra le XAML) et lourd (va falloir se taper encore un plugin super lourd dans nos pages web) , très peu pour moi. En tout cas, libre ou pas, les technos proposées par silverlight et flash, c'est pas vraiment du web pour moi. Ça n'est pas pour moi des technos ouvertes pour l'utilisateur, à moins qu'il existe des "décompilateurs" pour silverlight et flash, qui produisent du code lisible et hackable sans difficulté.. Mais j'ai comme un doute là, sur l'existence de ces trucs...
Impossible de lire le fichier video. Avec kaffeine, j'ai apparement du son (un bruit de rue) mais image noire. Avec d'autres, (VLC, Mplayer...), ça les fait carrément planté..
Quel est le codec à utiliser ? À moins que ce soit encore un vidéo dans un format propriétaire à peine supporté par les codecs libres ?
quand ils passeront à XulRunner 1.9.1/Firefox 3.1, z'auront plus besoin de faire ça :-) (enfin, pour les videos ogg en tout cas, pas sûr que le backend gstreamer soit inclus à temps)
Et sinon, quand ils passeront à XulRunner 1.9.2/Firefox 3.2 (pas sûr du numéro de version), ils pourront faire du SMIL pour les animations/présentations, plutôt que faire du Flash :-)
Et pour ceux qui n'aiment pas S5 (parce que c'est plutôt lent et lourd, sous Firefox en tout cas), il y a la possibilité de faire des pages HTML toute con, avec quelques classes bien placées (et que tu choisi), et tu installes l'extension FullerScreen pour Firefox, et c'est tout.
En plus, ça gère le media projection, et donc tu peux donner une apparence différente entre la visualisation traditionnelle et la visualisation en projection. Ça pourrait très bien être une page "normale" d'un site (donc c'est lisible "normalement", contrairement à S5, et par tout navigateur, même des vieux trucs), et quand on la met en projection, on vire par CSS les menus, entetes, tout ce qu'on ne veut pas en projection quoi, et avec un design adapté :-)
Et puis FullerScreen inclus un "navigateur" pour aller directement à une diapo donnée, en affichant une liste des screenshots de ces diapos. (merci la balise canvas)
ouuuhh là... Tu devrais te renseigner sur ce qu'on fait en PHP. Juste un exemple parce que je connais des devs de ces deux sites : les deux plus grosses plateformes de blogs françaises sont en PHP. (oui oui, une plateforme de blog, c'est une grosse appli, voir complexe, parce que cela doit apporter plein de fonctionnalités d'une part, mais aussi répondre à d'énormes contraintes comme la charge d'autre part)
Et je ne parle pas d'autres gros sites comme tf1, libé, lemonde.fr et cie.. Tous en PHP. Je pense ne pas me tromper en disant que parmis le top 10 des gros sites en france, la grande majorité sont en PHP.
Et je ne parle pas non plus de toutes ces applis métiers, intranet, complexes à souhait, en PHP (là c'est mon expérience qui parle).
>Le php de par sa nature bordelique et scriptee, non typee etc me parait une heresie pour developper une grosse appli.
Un peu de rigueur, de la programmation objet, et ça roule. Des applis propres en PHP, ça existent, et de plus en plus, grâce à l'utilisation de frameworks notamment, et à la "professionnalisation" des devs PHP.
En java, on peut en faire aussi du code très crade.
> Mais avant de pouvoir envoyer des données au serveur, le navigateur doit d'abord afficher un formulaire à l'utilisateur. Ce formulaire peut être vu comme une représentation de la ressource à modifier, au même titre que du HTML simple.
Pourquoi faudrait-il absolument un formulaire ?
Un navigateur (en tout cas Firefox 3 et IE), ont des possibilités d'édition d'une page web.
1) il est possible de spécifier avec l'attribut contenteditable les élements de la page qui sont éditable (tout les navigateurs ne prennent pas encore en charge cet attribut, Firefox3 et IE le font en tout cas) http://developer.mozilla.org/En/Rich-Text_Editing_in_Mozilla
2) on active l'édition en tapant sur la touche qu'il faut (F7 dans Firefox)
3) l'utilisateur peut alors modifier les parties de la pages qui sont éditables
Il manque juste un bouton "sauver" pour sauver le contenu de la page (POST ou PUT). Il me semble que Mozilla Composer/Nvu permettent de le faire, mais à vérifier. Mais de toute façon, c'est simple à implémenter, même par le biais d'une extension (dans une extension, un coup de serialization du DOM.
Àprès, au niveau du serveur, sur un POST ou PUT, rien de plus simple que de récupèrer le contenu des éléments modifiés (tout ceux qui ont l'attribut contenteditable, avec l'aide d'un parser SAX ou DOM), et de les sauver en base dans différents champs si on veut.
Pour bien des choses, surtout quand il s'agit d'édition de contenu pure, on a utilisé les formulaire fautes de mieux. Les formulaires n'ont jamais été prévu pour ce genre d'utilisation à l'origine.
Cependant, c'est vrai que souvent les formulaires sont pratiques, surtout quand on veut limiter la saisie (afficher une listbox pour proposer des choix par ex). Mais plutôt que d'étendre le protocole HTTP, un truc plus simple serait d'implémenter un évènement dans le navigateur, qui permettrait à la page web de savoir quand est ce que l'on sort ou qu'on rentre en mode édition, et donc de permettre d'afficher/de faire disparaitre des élements de formulaire. Couplez ça avec les possibilités offline de certains navigateurs, ça peut en être sympa :-) http://developer.mozilla.org/en/Offline_resources_in_Firefoxhttp://developer.mozilla.org/en/Online_and_offline_events
Amaya aussi permet l'édition de pages distantes et sait faire du PUT, DELETE et cie.
>Après, il reste le problème de l'autorisation de modification de ressources Web ...
Il y a tout ce qu'il faut dans HTTP pour s'authentifier. Après au serveur web de savoir ce que l'utilisateur authentifié a le droit de faire. Par défaut, il me semble qu'apache se base tout simplement sur les droits systèmes des fichiers. Mais mettre un autre système de droit en place est possible aussi, puisque dans apache on peut utiliser une base de donnée mysql par exemple..
M'enfin un autre problème pour l'édition : ce sont les ressources "virtuelles", celles qui ne sont pas des fichiers physiques. c'est à dire le contenu généré à la volée. Là c'est au système de gestion de contenu de prendre en charge PUT, DELETE et cie... Malheureusement, tout les modules de langages ne prennent pas forcément correctement en charge ces méthodes. Dans PHP par exemple, pour PUT, il faut parser soit même le body de la requete, alors qu'il le fait très bien pour POST. Si du multipart/form-data, il met le contenu dans $_POST et $_FILES, si c'est du urlencoded machine bidule jesaisplusquoi, il met dans $_POST etc.. Et ça il ne le fait pas pour PUT, ce qui est embétant... Il me semble aussi que l'on ne reçoit pas les requêtes HEAD (à vérifier) dans PHP.
Avoir une somme de contrôle correspondant à un fichier, c'est bien, mais il faut avoir le fichier pour calculer la somme et la comparer avec celle que l'on a récupéré, pour savoir si le fichier corresponds. Donc il faut nécessairement télécharger le fichier.
Je n'ai pas dit que la AGPL interdisait d'apporter des modifications.
Ce que j'en ai compris de la AGPL :
- tu dois fournir les sources à tout les utilisateurs de l'appli web
- si tu fais des modifs, tu dois aussi les fournir
Ce qui veut dire que tout utilisateur de la boite, doit avoir accès aux sources, et donc même aux modifications qui pourrait concerner la gestion de données spécifiques et sensibles. Donc même aux utilisateurs qui ne sont pas habilités à connaître la présence/la gestion de ces données sensibles, car n'ayant pas de rapport avec eux ou le service dans lequel ils travaillent.
Si ce que j'ai compris est bon, je trouve donc ça très moyen de mettre un tel logiciel sous AGPL.
Pas besoin d'une imprimante. Faut juste que tu branches un distributeur de billet sur ton laptop, via une prise USB, et un plugin flash gère la communication entre le navigateur et le distributeur.
C'est pourtant simple !!
Oui bon, faut se déplacer pour être à coté d'un distributeur de billet...
Mais il parait qu'ils vont améliorer ça, et bientôt les distributeurs pourront communiquer par wifi (parce que bon, se balader avec un cordon usb, c'est pas cool..).
Certains disent d'ailleurs qu'un jour peut-être, on n'aura plus besoin de prendre son laptop pour retirer de l'argent à un distributeur. Mouarf, y en a qui rêve quand même...
je trouve ça plutôt con, pour un logiciel utilisé en entreprise. Car cela veut dire que la boite ne peut pas apporter des modifications qui seraient propre à son fonctionnement, et donc des modifs qui ne sont pas forcément intéressantes pour les autres, encore moins si il s'agit de choses confidentielles.
Ah ouai ? et y a que ça à photographier en France ??? Arrête la mauvaise foi...
Si quelqu'un veut faire partager une photo d'un petit monument de son bled, ou même des fleurs de son jardin, il a 99% de chances que la carte openstreetmap n'a pas de plan du coin photographié.
Je ne dénigre absolument pas le travail remarquable fait par les contributeurs à OpenStreetMap, mais en toute franchise, je ne pense pas que ce soit utilisable en l'état pour une application comme Vision2pixels..
qu'est ce qu'on a à fiche de la somme de contrôle ici ? Le fichier a déjà été téléchargé avant de pouvoir vérifier cette somme. Et donc tu es déjà dans "l'illégalité" pour détention d'un fichier illicite.
(je dis pas qu'il faut pas vérifier la somme de contrôle hein... mais bon, dans le contexte...)
[^] # Re: And it's no, nae, never ! No, nae, never no more !
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal un petit pas de MS vers le libre. Évalué à 4.
J'ai oublié de préciser : dans un navigateur "graphique". Ce que je voulais dire par là, c'est que le contenu web est accessible par d'autres moyens qu'un navigateur graphique (moteur d'indexation par exemple, lecteur vocaux etc). Ce n'est pas le cas de Flash... Il faut obligatoirement un lecteur flash, ou alors se faire un analyseur de blob flash, mais c'est pas évident à faire, alors que parser du HTML, c'est du texte, donc au pire, quelques regexp pour accéder à des informations spécifiques peuvent suffire, sans compter les nombreuses implémentation DOM.
Pour ce qui est de la technique, je suis bien d'accord que flash rend certains services aux développeurs, je l'ai même signalé à la fin de mon commentaire. Mais le débat n'est pas là. Le débat portait sur le fait que Flash n'est PAS une technologie "web". C'est une technologie pour faire des applications. Point. Mais ce n'est pas web, car ça ne suit pas la philosophie du Web. Ça ne comporte pas les concepts qui font le Web.
>SVG ca fait des annees qu'on nous bassine avec, et ca n'a toujours rien donne,
Y a pourtant des implémentations dans les principaux moteurs, il y avait un plugin Adobe etc... Certes, elles ne sont pas complète, mais ça fonctionne quand même, et ça s'améliore. La non-expansion de SVG est surtout dû à IE. Et puis aussi au rouleau marketing d'Adobe avec son flash.
>et personne n'a prit la peine de developper des outils autour.
Ça c'est complètement faux. Adobe propose des outils pour faire du SVG par exemple. Et Inkscape, l'éditeur SVG libre, très complet je trouve, c'est du vent ?
>Pour revenir a la source du probleme, concernant ton laius sur les brevets, j'aimerais bien que tu me prouves formellement que ogg/theora est libre de tout brevet.
Il y a des suspicions, mais personne n'en n'est sûr, c'est l'une des raisons pour lesquelles la recommandation du format ogg a été retirée de la spec HTML5. Mais as-tu un format video plus ouvert et plus "libre" de tout brevet, que Ogg ?
En tout cas, Mozilla n'hésite pas à l'inclure dans Firefox. C'est donc qu'il ne doit pas y avoir tant de risque que ça.
[^] # Re: And it's no, nae, never ! No, nae, never no more !
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal un petit pas de MS vers le libre. Évalué à 3.
ET ALORS ? C'est déjà un premier pas, qu'il y ait au moins une spécification pour lire de la vidéo. C'est déjà un bon départ, un socle, pour promouvoir l'utilisation de format libre de video. Tu crois que c'est avec Flash ou Silverlight qu'un jour tout le monde utilisera Ogg Theora ou autre format libre ?
Si on commence pas par un bout, par cette balise video, aucune chance que des formats videos ouverts soient intensivement utilisés sur le web.
>Parcqu'il n'y a pas beaucoup de raison technique de l'utiliser : moins bonne qualité, peu implémenté par les softs et le hard.
Pour la qualité, c'est un bon troll des familles, d'une part. Et d'autre part, pour ce qui est de l'implémentation, on en reparlera dans un an (voir moins), quand Firefox 3.1 aura remplacé la majeure partie des installations de Firefox 3.0 actuelles. Un support natif de Ogg Theora sur 30% des machines d'internautes, ça ne sera pas significatif selon toi ?? Hein ?? (et je compte pas les installations de webkit et opera) Ce sera moins bien que le 1% actuel ? (au pif, mais je dois pas être loin, sinon très optimiste sur ce chiffre)
Et tu va encore me dire, "sera peu utilisé sur les sites web, bla bla bla". Oui mais si on offre absolument rien aux développeurs web pour qu'il puisse utiliser un format ouvert, là encore, aucune chance que ces formats se propagent.
Bref, cette balise video c'est une opportunité pour la propagation des formats ouverts. C'est sûr, au debut, tout le monde va pas se jeter sur ogg theora, mais au moins, il y aura dans les navigateurs plus de moyen de les utiliser qu'actuellement. Donc ça viendra.
Franchement, c'est dingue ton defaitisme. Parce que oui, c'est vraiment du defaitisme que tu nous fais là.
Alors oui, je suis un libriste "qui se branle la nouille" sur une balise web, parce que je vois en cette technologie une formidable opportunité pour promouvoir des formats ouverts et libres.
>Mais flash normalise le contenu,
je ne sais pas ce que tu appelle par "normalise", mais excuse moi, HTML5 est tout de ce qu'il y a de plus normalisé, et n'est de plus, pas un format contrôlé par une seule entreprise.
[^] # Re: And it's no, nae, never ! No, nae, never no more !
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal un petit pas de MS vers le libre. Évalué à 10.
Le web, c'est un socle reposant sur des technologies ouvertes et accessibles, dans tous les sens des termes, et qui sont dans la lignée de la philosophie du concepteur du web, Tim Berners-Lee.
Silverlight et Flash, ce ne sont pas des technologies web. Pourquoi ? Pour faire vite :
- leurs specifications ont beau s'ouvrir, ça reste des spécifications propriétaires. Car ces spécifications restent dans les mains d'une même boite. Va donc toi, entreprise, ou expert, aller participer à leur élaboration. Ce n'est pas le cas des vrais technos web, dont les specs sont développés au sein d'un consortium, et ou chacun peut participer. Bref, la soit-disant "ouverture" de ces specs proprio, c'est de la poudre aux yeux. Et je ne parle pas des menaces juridiques de leur implémentation. Rien ne garanti que Adobe ou MS ne vont pas un jour tomber sur les auteurs d'une implémentation tierce (peu importe la raison), pour violation de Brevet, ou autre. Aucune chance que ça arrive avec les technologies web. Les spécifications normalisées au W3C sont librement implémentable et libre de tout brevet logiciel ou autre (ou en tout cas, les entreprises à l'origine de ces technos n'ont pas le droit de demander royalties ou de poursuivre juridiquement un implémenteur ou un utilisateur)
- les applis développés avec flash ou silverlight, ce sont des boites noires. Tu ne peux pas voir le code source. Avec les technologies web, si. Tu fais un view source dans ton navigateur, et tu as accès au code source. Instantanément. Tu peux donc apprendre, vérifier, comprendre comment la page web ou l'appli web fonctionne (au moins coté client). Combien de développeur web ont commencé en faisant un view source, au moins juste par curiosité ? À peu prés tous. Va donc faire ça avec un blob pour un plugin flash ou silverlight... Ça n'a l'air peut être rien pour toi, mais si le web s'était construit sur des technos aussi fermées pour l'utilisateur que le flash, eh bien le web n'existerait pas, et on serait probablement en train d'utiliser des "navigateurs" (si on peut appeler ça) spéciaux sur un reseau AOL ou MSN, tel que cela avait été imaginé par MS et AOL dans les années 90 pour "contrer" ce web merveilleux et ouvert tel qu'on le connait aujourd'hui. On serait donc enfermer dans un réseau dont on aurait aucun contrôle. Et avec Silverlight et Flash, ils tentent à nouveau de "contrôler" ce type de web fermé.
À propos de contrôle, les technologies web, par leur ouverture, permettent à l'utilisateur d'en contrôler le fonctionnement, ou tout au moins l'affichage. As-tu un jour pu faire un copier-coller de n'importe quel morceau de texte affiché par du flash ? As-tu pu un jour zoomer, changer les couleurs, sur du texte ou des dessins affichés par du flash ? As-tu pu un jour contrôler totalement l'affichage de ce que présente une appli flash ? As-tu pu utiliser une application flash en dehors d'un navigateur "classique" desktop ? As-tu pu afficher directement une "page" d'une application flash ? Assurément, toutes les réponses sont non. Par contre, pour les technologies web, si. Parce qu'elle le permettent, parce qu'elles sont conçus pour être accessible un maximum, pas forcément à ceux atteint d'un handicap, mais vraiment accessible à TOUT le monde et à TOUTE application. La preuve en est aussi le succés de greasemonkey, des bloqueurs de pubs, des moteurs de recherches, sans parler des possibilités pour l'utilisateur d'appliquer des feuilles de styles spécifiques à un site, de contrôler ce qui peut être fait ou non dans une page web (l'execution de code js, l'affichage des images etc). Bref, avec les vrais technologies web, l'utilisateur garde le contrôle du contenu. Avec Flash et Silverlight, pas du tout.
D'autres mots qui me viennent à l'esprit pour décrire le web : UNIVERSALITÉ, mais aussi LIENS HYPERTEXTES. Avec cette ouverture du code, ce degré d'accessibilité tant à l'information qu'au code source, tous ça est vraiment ce qui caractérise le web, qui a servi à l'expansion du web, et qui a fait son succès. Et ce n'est absolument pas des technos comme flash ou silverlight qui vont améliorer ces caractéristiques. Elles ne sont pas conçu pour.
Bref, ce n'est pas parce qu'on peut les utiliser dans un page web, et qu'elles sont peut-être "sexy" à utiliser pour les développeurs, que ce sont des technos dites "web". Pas dans le sens noble et original du terme "web". Ce sont des technos. Point. Mais pas web.
[^] # Re: And it's no, nae, never ! No, nae, never no more !
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal un petit pas de MS vers le libre. Évalué à 5.
[^] # Re: Et pendant ce temps-là, au Parti Communiste...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal un petit pas de MS vers le libre. Évalué à 1.
[^] # Re: And it's no, nae, never ! No, nae, never no more !
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal un petit pas de MS vers le libre. Évalué à 3.
[^] # Re: And it's no, nae, never ! No, nae, never no more !
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal un petit pas de MS vers le libre. Évalué à 7.
<video src="mavideo.ogg">
<object>
<param name="movie" value="flvplayer.swf?file=mavideo.flv"></param>
<embed src="flvplayer.swf?file=mavideo.flv" type="application/x-shockwave-flash">
</embed>
</object>
</video>
Ta video, elle s'affichera quoi qu'elle arrive. Si le navigateur ne connait pas la balise video, il saura l'afficher si il y a le plugin flash.
Avantage : à ceux qui auront un navigateur supportant la balise video, on pourra leur fournir par exemple une video de meilleure qualité. Sans compter une accessibilité autrement meilleur qu'un truc pourri en flash, et tout les avantages qu'apportent la balise video par rapport à object. http://ljouanneau.com/blog/post/2007/04/17/659-la-balise-video (ce billet date un peu, la recommandation vis à vis de ogg a été enlevée).
Pour ce qui est dans l'implémentation dans les navigateurs, sans nulle doute que les développeurs des navigateurs vont faire comme Mozilla, pour ne pas être "à la traine" : permettre de prendre en charge un maximum de formats video en s'appuyant sur ce que propose le système d'exploitation. Les internautes vont forcément préférer le navigateur qui leur permettra une meilleure "expérience utilisateur".
Bref, pour la compatibilité entre navigateur, je ne m'en fais pas du tout, ça va venir.
En tout cas, il est triste ton avis sur les standards du web. Mais bon, libre à toi de soutenir les technos semi-propriétaire de Microsoft ou Adobe...
[^] # Re: Et pendant ce temps-là, au Parti Communiste...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal un petit pas de MS vers le libre. Évalué à 2.
[^] # Re: And it's no, nae, never ! No, nae, never no more !
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal un petit pas de MS vers le libre. Évalué à 6.
mouai... donc la balise video et audio dans Firefox 3.1 (qui sort à la fin de l'année), dans Opera (et dans webkit, je sais plus), c'est du vent ? Firefox contient un backend ogg theora en standard, et d'autres backend vont arriver (directmedia, gstreamer etc).
Pour les animations, SMIL commence à pointer le bout de son nez chez webkit, opera et Firefox (ça fait parti du test acid3) et il existe déjà dans IE depuis quelques années (ou a existé, je ne sais plus, et est utilisé dans window media player). C'est pas du serieux ?
D'ici un an, on aura des implémentations SMIL et video dans quasi tout les navigateurs. Je crois qu'on peut attendre un peu, ou même commencer à utiliser ces technos.
Sans parler que Mozilla vient d'annoncer la création d'un projet d'outils pour développeur web, qui, on peut l'éspérer, tiendra compte des technos récentes incluses dans nos navigateurs préférés. http://labs.mozilla.com/2008/10/developer-tools-and-the-open(...)
Alors bon, les trucs à moitié libre, super verbeux (c'est vraiment cracra le XAML) et lourd (va falloir se taper encore un plugin super lourd dans nos pages web) , très peu pour moi. En tout cas, libre ou pas, les technos proposées par silverlight et flash, c'est pas vraiment du web pour moi. Ça n'est pas pour moi des technos ouvertes pour l'utilisateur, à moins qu'il existe des "décompilateurs" pour silverlight et flash, qui produisent du code lisible et hackable sans difficulté.. Mais j'ai comme un doute là, sur l'existence de ces trucs...
# format video ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Rasterman passe au Treo-650 et continue d'améliorer e17. Évalué à 3.
Quel est le codec à utiliser ? À moins que ce soit encore un vidéo dans un format propriétaire à peine supporté par les codecs libres ?
[^] # Re: Mes multiples expériences...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Nom de nos machines. Évalué à 2.
Bon sinon, moi j'utilise les noms des constructeurs de vaisseaux en tout genre dans la guerre des étoiles :-)
[^] # Re: SCENARI
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Faire une présentation pour une conférence ?. Évalué à 2.
quand ils passeront à XulRunner 1.9.1/Firefox 3.1, z'auront plus besoin de faire ça :-) (enfin, pour les videos ogg en tout cas, pas sûr que le backend gstreamer soit inclus à temps)
Et sinon, quand ils passeront à XulRunner 1.9.2/Firefox 3.2 (pas sûr du numéro de version), ils pourront faire du SMIL pour les animations/présentations, plutôt que faire du Flash :-)
[^] # Re: S5
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Faire une présentation pour une conférence ?. Évalué à 8.
https://addons.mozilla.org/fr/firefox/addon/4650
En plus, ça gère le media projection, et donc tu peux donner une apparence différente entre la visualisation traditionnelle et la visualisation en projection. Ça pourrait très bien être une page "normale" d'un site (donc c'est lisible "normalement", contrairement à S5, et par tout navigateur, même des vieux trucs), et quand on la met en projection, on vire par CSS les menus, entetes, tout ce qu'on ne veut pas en projection quoi, et avec un design adapté :-)
http://disruptive-innovations.com/zoo/fullerscreen/samples/p(...)
Et puis FullerScreen inclus un "navigateur" pour aller directement à une diapo donnée, en affichant une liste des screenshots de ces diapos. (merci la balise canvas)
[^] # Re: mon avis
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Cherche développeur web. Évalué à 4.
Et je ne parle pas d'autres gros sites comme tf1, libé, lemonde.fr et cie.. Tous en PHP. Je pense ne pas me tromper en disant que parmis le top 10 des gros sites en france, la grande majorité sont en PHP.
Et je ne parle pas non plus de toutes ces applis métiers, intranet, complexes à souhait, en PHP (là c'est mon expérience qui parle).
>Le php de par sa nature bordelique et scriptee, non typee etc me parait une heresie pour developper une grosse appli.
Un peu de rigueur, de la programmation objet, et ça roule. Des applis propres en PHP, ça existent, et de plus en plus, grâce à l'utilisation de frameworks notamment, et à la "professionnalisation" des devs PHP.
En java, on peut en faire aussi du code très crade.
[^] # Re: Ca arrive tout les jours...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal [HS] Selon que vous serez puissant ou misérable.... Évalué à 6.
(oui, je chipotte)..
# Pourquoi un formulaire ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Éditer une ressource HTTP. Évalué à 2.
Pourquoi faudrait-il absolument un formulaire ?
Un navigateur (en tout cas Firefox 3 et IE), ont des possibilités d'édition d'une page web.
1) il est possible de spécifier avec l'attribut contenteditable les élements de la page qui sont éditable (tout les navigateurs ne prennent pas encore en charge cet attribut, Firefox3 et IE le font en tout cas) http://developer.mozilla.org/En/Rich-Text_Editing_in_Mozilla
2) on active l'édition en tapant sur la touche qu'il faut (F7 dans Firefox)
3) l'utilisateur peut alors modifier les parties de la pages qui sont éditables
Il manque juste un bouton "sauver" pour sauver le contenu de la page (POST ou PUT). Il me semble que Mozilla Composer/Nvu permettent de le faire, mais à vérifier. Mais de toute façon, c'est simple à implémenter, même par le biais d'une extension (dans une extension, un coup de serialization du DOM.
Àprès, au niveau du serveur, sur un POST ou PUT, rien de plus simple que de récupèrer le contenu des éléments modifiés (tout ceux qui ont l'attribut contenteditable, avec l'aide d'un parser SAX ou DOM), et de les sauver en base dans différents champs si on veut.
Pour bien des choses, surtout quand il s'agit d'édition de contenu pure, on a utilisé les formulaire fautes de mieux. Les formulaires n'ont jamais été prévu pour ce genre d'utilisation à l'origine.
Cependant, c'est vrai que souvent les formulaires sont pratiques, surtout quand on veut limiter la saisie (afficher une listbox pour proposer des choix par ex). Mais plutôt que d'étendre le protocole HTTP, un truc plus simple serait d'implémenter un évènement dans le navigateur, qui permettrait à la page web de savoir quand est ce que l'on sort ou qu'on rentre en mode édition, et donc de permettre d'afficher/de faire disparaitre des élements de formulaire. Couplez ça avec les possibilités offline de certains navigateurs, ça peut en être sympa :-) http://developer.mozilla.org/en/Offline_resources_in_Firefox http://developer.mozilla.org/en/Online_and_offline_events
[^] # Re: PUT -> remplacement ou création d'une ressource
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Éditer une ressource HTTP. Évalué à 3.
>Après, il reste le problème de l'autorisation de modification de ressources Web ...
Il y a tout ce qu'il faut dans HTTP pour s'authentifier. Après au serveur web de savoir ce que l'utilisateur authentifié a le droit de faire. Par défaut, il me semble qu'apache se base tout simplement sur les droits systèmes des fichiers. Mais mettre un autre système de droit en place est possible aussi, puisque dans apache on peut utiliser une base de donnée mysql par exemple..
M'enfin un autre problème pour l'édition : ce sont les ressources "virtuelles", celles qui ne sont pas des fichiers physiques. c'est à dire le contenu généré à la volée. Là c'est au système de gestion de contenu de prendre en charge PUT, DELETE et cie... Malheureusement, tout les modules de langages ne prennent pas forcément correctement en charge ces méthodes. Dans PHP par exemple, pour PUT, il faut parser soit même le body de la requete, alors qu'il le fait très bien pour POST. Si du multipart/form-data, il met le contenu dans $_POST et $_FILES, si c'est du urlencoded machine bidule jesaisplusquoi, il met dans $_POST etc.. Et ça il ne le fait pas pour PUT, ce qui est embétant... Il me semble aussi que l'on ne reçoit pas les requêtes HEAD (à vérifier) dans PHP.
[^] # Re: C'est la deuxième lame ...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal L'aurions-nous dans le c.. ?. Évalué à 3.
Avoir une somme de contrôle correspondant à un fichier, c'est bien, mais il faut avoir le fichier pour calculer la somme et la comparer avec celle que l'on a récupéré, pour savoir si le fichier corresponds. Donc il faut nécessairement télécharger le fichier.
[^] # Re: C'est la deuxième lame ...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal L'aurions-nous dans le c.. ?. Évalué à 3.
[^] # Re: De bonnes idées
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Lundi Matin Business, un nouveau logiciel de gestion commerciale OpenSource. Évalué à 2.
Ce que j'en ai compris de la AGPL :
- tu dois fournir les sources à tout les utilisateurs de l'appli web
- si tu fais des modifs, tu dois aussi les fournir
Ce qui veut dire que tout utilisateur de la boite, doit avoir accès aux sources, et donc même aux modifications qui pourrait concerner la gestion de données spécifiques et sensibles. Donc même aux utilisateurs qui ne sont pas habilités à connaître la présence/la gestion de ces données sensibles, car n'ayant pas de rapport avec eux ou le service dans lequel ils travaillent.
Si ce que j'ai compris est bon, je trouve donc ça très moyen de mettre un tel logiciel sous AGPL.
[^] # Re: Bonne imprimante ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal La caisse d'épargne ne répond plus. Évalué à 1.
C'est pourtant simple !!
Oui bon, faut se déplacer pour être à coté d'un distributeur de billet...
Mais il parait qu'ils vont améliorer ça, et bientôt les distributeurs pourront communiquer par wifi (parce que bon, se balader avec un cordon usb, c'est pas cool..).
Certains disent d'ailleurs qu'un jour peut-être, on n'aura plus besoin de prendre son laptop pour retirer de l'argent à un distributeur. Mouarf, y en a qui rêve quand même...
[^] # Re: De bonnes idées
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Lundi Matin Business, un nouveau logiciel de gestion commerciale OpenSource. Évalué à 2.
je trouve ça plutôt con, pour un logiciel utilisé en entreprise. Car cela veut dire que la boite ne peut pas apporter des modifications qui seraient propre à son fonctionnement, et donc des modifs qui ne sont pas forcément intéressantes pour les autres, encore moins si il s'agit de choses confidentielles.
Je n'aime vraiment pas la AGPL...
[^] # Re: Géolocalisation
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Vision2Pixels: un moteur de critique photographique libre. Évalué à -1.
Si quelqu'un veut faire partager une photo d'un petit monument de son bled, ou même des fleurs de son jardin, il a 99% de chances que la carte openstreetmap n'a pas de plan du coin photographié.
[^] # Re: Géolocalisation
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Vision2Pixels: un moteur de critique photographique libre. Évalué à 8.
"Bonjour, j'ai pris ma photo ici : http://www.openstreetmap.org/?lat=48.42924&lon=-0.86181&(...) "
Ouai.. super... vachement intéressant..
Je ne dénigre absolument pas le travail remarquable fait par les contributeurs à OpenStreetMap, mais en toute franchise, je ne pense pas que ce soit utilisable en l'état pour une application comme Vision2pixels..
[^] # Re: C'est la deuxième lame ...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal L'aurions-nous dans le c.. ?. Évalué à 5.
(je dis pas qu'il faut pas vérifier la somme de contrôle hein... mais bon, dans le contexte...)