Larry Cow a écrit 5011 commentaires

Et j'ai beau chercher je ne vois pas en quoi il est plus limité que les autres.

Ne soit pas de mauvaise foi non plus. FFOS est parti pour être le seul système d'exploitation moderne à ne pas permettre l'accès à internet (i.e. pas juste au web) à ses applications. C'est cohérent avec la logique de Mozilla (qui reste un des plus grands moteurs du web), mais c'est une limitation. Et pas vraiment un point de détail.

Sur mes systèmes d'exploitation, des applications qui se connectent à des services non-web (et non websocket), j'en ai des pelletées. Toi aussi, je présume. Même sur mon téléphone, c'est assez courant : client SSH, client mail, client Jabber, portefeuille bitcoin, client SMB, client MPD… Sans parler de mon FTPD pour quand j'ai besoin d'accéder au contenu du téléphone depuis un ordinateur qui parle mal le MTP. Tout n'est pas indispensable, loin de là, mais un smartphone non plus si on y réfléchit.

Note: oui je sais, beaucoup de serveurs XMPP proposent du BOSH, voire des Websockets, mais pas tous… c'est ça le point. Avec FFOS, on ne peut se connecter que chez les gens qui ont prévu le coup.

Depuis le temps que je milite pour qu'on code en latin…

Et tu ne pourrais pas utiliser les websockets parce que … ?

Parce qu'en l'absence du grand Ternet, il faudrait que l'un des téléphones endosse le rôle de serveur? (ou tous, dans le cas de Serval)

Si le truc est un tant soit peu sécurisé, sa fera juste des handshake HTTP en boucle. Donc la même chose qu'une boucle de requètes ajax - les serveurs web modernes gèrent pas trop mal ce genre de trucs.

Rien de pire que sans WebSocket quoi. Enfin l'idée c'était qu'il y avait déjà tellement de conneries à faire sans accès direct aux sockets qu'à la limite ça ne changeait pas grand chose d'y avoir accès.

Du genre ce truc : http://www.networkworld.com/news/2013/080113-black-hat-ddos-botnets-272447.html

(meême si franchement j'ai du mal à voir l'interet - à part un proxy en tethering peut-être)

Un moyen de mettre en réseau des FFOS-phones en l'absence de connexion au grand 'ternet? Genre jeu en réseau (local), ou mesh-networking (un port de Serval, quelqu'un?).

a - Non on ne peut pas ouvrir n'importequel socket TCP ou UDP de n'importe quel IP depuis une webapp (Et heureusement d'ailleurs, si il suffisait de trois lignes de javascript pour que toute personne qui visite un site se mette à faire du DOS sur telle ou telle IP j'imagine pas le carnage).

Merci, c'est précisément ce qu'on vous demande depuis deux heures, et que vous (enfin surtout l'autre) mettez une mauvaise volonté patente à nous dire ouvertement que NON on ne peut pas se connecter sur n'importe quel serveur (logiciel, s'entend).

b - De toute façon pour qu'une webapp marche (et à forciori un websocket) il faut un serveur web qui sert les infos quelque part. Pour les apps simple on peut se contenter d'un stockage fichier (j'imagine que c'est comme ça que fonctionnent les applis non connectées dans FFOS). Pour les applis connectés et les websockets il faut sortir un vrai serveur web avec à minima le handshake pris en charge.

Merci encore de le reconnaître, c'est une sacrée différence avec le reste de l'offre smartphonesque actuelle (vu que WebOS n'est plus et qu'Apple s'est assez rapidement mis aux applis natives). Je ne dis pas que ça ne peut pas marcher, mais il faut arrêter d'essayer de faire croire aux gens que ça sera "tout pareil qu'avec leur iAndroidBerry".

• Est-ce qu'une webapp classique (FFOS ou autre) peut se connecter directement à un annuaire LDAP ou à un serveur IRC : non, clairement c'est pas fait pour.

Merci encore. Laissez pas des gens communiquer de manière ambiguë (voire mensongère) autour de ça, les gars. Le premier développeur (un peu bête, certes) qui va se laisser tenter par la plateforme sans se rendre compte de cette limitation va vous faire la pire pub qui soit.

• Est-ce qu'une webapp peut se connecter sur n'importe quel serveur pour peu qu'il y ait un convertisseur websocket/tcp quelque part : oui. A noter ca ne marche bien qu'avec le TCP, en UDP ca devient glissant très vite, les websockets s'attendent à ce qu'on leur réponde systématiquement - il faut donc que le convertisseur "invente" des réponses quand il n'y en a pas, ca se fait mais c'est lourdingue.

À n'importe quel serveur TCP appareillé d'un convertisseur. Important comme précision, non? ;)

• Est-ce qu'on peut faire autrement : Oui - https://developer.mozilla.org/en-US/docs/Web/API/TCPSocket il y a toute une API qui permet d'accéder aux bons vieux socket TCP depuis une webapp MAIS c'est pas vraiment comme ça qu'on fait une webapp normalement ET ca ne marche que pour les applis certifiées ou privilégiées.

On est d'accord. Bon, ça met un clou de plus dans la comm' de ton comparse qui nous vendait du "Firefox mobile […] full-compatible FFOS", mais c'est un choix qui se défend.

Voilà pour la théorie, reste à voir ce que ca va donner dans la pratique.

Et ne te méprends pas, je suis aussi curieux qu'on autre, sinon davantage. J'aime juste pas qu'on me baratine ;)

Pour être clair tu peux ouvrir des connexions vers n'importe quel serveur en utilisant soit les websockets, soit les API socket.IO. Et les deux s'invoquent en quelques lignes de javascript. Bien entendu tu n'as pas à faire "npm install socket.io", l'API est déjà présente par défaut.

Ok, ça s'éclaircit. Et c'est valable pour n'importe quel navigateur (moderne, s'entend), ou simplement FFOS?

Parce que quand je lis la page http://socket.io/#browser-support je déchante un peu. Je cite :

Supported transports:

* WebSocket
* Adobe® Flash® Socket
* AJAX long polling
* AJAX multipart streaming
* Forever Iframe
* JSONP Polling

Tout ça c'est bien joli, mais c'est pas avec ça que je vais pouvoir me connecter à mon (vieil) OpenLDAP ou à mon serveur IRC préféré.

Tu lis ce que tu postes, parfois?

Je cite le repo github :

This repo provides:

   * "Client daemon" logic that is the backend. It does the IMAP protocol talking, storage maintenance, etc. It communicates over a JSON bridge with the front-end which provides the:
   * MailAPI, for use by the UI/front-end. It communicates asynchronously with the back-end over the JSON bridge.

Concrètement, je ne peux pas me connecter à n'importe quel serveur IMAP. Il faut que j'ai un composant (non-web), le fameux "Client daemon", qui va se charger de traduire IMAP en "HTTP+JSON" (et retour) pour la fameuse MailAPI. Alors certes, FFOS peut embarquer le dit-composant (je suppose qu'ils vont avoir NodeJS à bord, en ce cas). Mais si je veux me connecter à autre chose que de l'IMAP (par exemple une version subtilement différente, ou qui utilise un mécanisme d'authentification non-standard), je vais me faire voir.

Très sérieusement, il faut arrêter là, ça va finir par se voir. FFOS est une excellente initiative. Il y a beaucoup de bon dedans, et ils ont déjà fait pas mal de chemin. Mais il y a encore des GROSSES lacunes par rapport à des plateformes plus conventionnelles. Certaines de ces lacunes sont intentionnelles (le fait de ne pas avoir d'applications natives), d'autres non. Mais faire comme si elles n'existaient pas ne va faire que générer des frustrations autour d'un produit qui me semble avoir pas mal d'avenir.

Les socket RAW, UDP, et TCP sont supportés et accessibles sur tous les vrais navigateurs via les websocket et socket.io.

Soit j'ai rien compris du tout à socket.io, soit ça nécessite d'avoir un truc qui tourne côté serveur pour encapsuler les websockets. Bref, c'est pas ce que j'appelle supporter les "sockets RAW, UDP et TCP" (en tous cas pas juste avec les "vrais navigateurs" tous seuls).

Où tu constatera (comme moi) que certaines API sont FFOS spécifiques, et c'est bien dommage. L'objectif à terme est d'avoir ces apis fans Firefox, je crois.

Certaines APIs, oui. Je compte 18 "device API", dont seulement 2 supportées par FF mobile (et une seule par FF normal).

Après, je me doute bien que le but est d'harmoniser tout ça. Mais dire que c'est actuellement possible, c'est mensonger.

PS: On notera que la fameuse API "tcp-socket", qui permet justement de contacter le "vrai internet" (cf. post plus bas) (et sans rajouter un proxy côté serveur) n'est pas accessible sur FF mobile. Avec la petite mention "Note: Only certified apps can use a port below 1024." (on se rappellera que les applications "certifiées" sont celles préinstallées par l'opérateur, pas celles que l'utilisateur autorise).

socket.io et les websockets sont tes amis.

Avec ces deux magnifiques technologies, je peux me connecter au serveur IMAP de ma boîte? Sans modifier le-dit serveur, évidemment, sinon c'est de la triche.

Full-compatible? Vraiment?

Il m'avait semblé, sauf si ça a changé depuis, qu'il ne disposait pas de toutes les applis de FFOS. Donc si les applis sont suffisamment simples, ça va, mais il ne faut pas qu'elles utilisent des trucs trop sioux (genre ouverture de sockets TCP comme dans le cadre d'un client mail, par exemple).

c'est encore pour moi les marais de la mélancolie :p

Arthaaaax!

Vaadin est une sorte de Qt côté serveur qui utilise Gwt côté client comme bibliothèques de widgets.

Donc pas du tout un équivalent de Pyjamas, quoi :)

C'est pas déjà en Java, GWT? Vaadin est un équivalent en Java d'un truc en Java?

Malheureusement, l'IDE en question n'est ni libre, ni multiplateforme.

Ce qui répond à la question "il faut tout dire?" ;)

Car on s'en fout un peu pour l'application ici de ce qu'il y a derrière la virgule.

Certes, mais pas si tu arrondis, justement. Parce que si tu alterne entre 18.99 et 19.01, ça va te faire tout drôle.

Ya pas de faux ami en anglais, on le sait tous.

En l’occurrence, là ce n'est pas le cas.

Ah pardon, j'ai téléscopé ça avec Seaside/Opa/…

Pyjamas (et GWT dont il s'inspire largement) ont un paradigme assez différent des frameworks usuels : ils se chargent du code serveur (comme Django, donc) ET du code client.

C'est à dire que tu vas écrire l'intégralité de ton application web en Python, que le code soit prévu pour être exécuté sur le serveur ou dans le navigateur. Et Pyjamas va se charger de générer le code Javascript qui va bien pour que ça fonctionne.

Tu es dur, tout de même. Avec un chiffre et un caractère spécial de plus, ça ferait un mot de passe tout à fait correct.

Tiens, ça me fait penser à un truc. Avec toutes ces nouvelles "mini-cartes pas cher", il n'y en a encore aucune qui vient avec plusieurs ports Ethernet (voire du Wi-Fi en sus), histoire de pouvoir se (re)-faire des routeurs maison? Parce que c'est nettement moins cher que du Soekris.

En même temps, tu as déjà essayé de prononcer "pain" avec l'accent toulousain?

Ou encore le mec de Skyrock qui a fait larmoyer son monde après que les vilains actionnaires l'aient foutu à la porte.

En quoi mettre ta clé dans ton téléphone la rend plus vulnérable que la mettre sur ton pc ?

Le vol de PC à l'arraché, c'est plus difficile, tout de même.