Objective Cloud

FKDEVFKDEV Membre
novembre 2012 modifié dans Langages Web & serveurs #1
Via Macg : http://www.macg.co/news/voir/257766/developpeurs-les-outils-de-developpement-d-apple-dans-le-nuage



Il y avait déjà  eu des projets pour faire du web côté serveur en Objective C sur Mac mais celui-ci semble se concentrer sur la fourniture d'API REST plutot que sur la fourniture de page HTML.

Je trouve ça malin de se limiter dans un premier temps.





J'aurais bien aimé avoir l'idée de ce projet, techniquement cela ne doit pas être très compliqué à  mettre en place. J'avais déjà  fait des essais sur Mac via FastCGI, et ça fonctionne plutôt bien.

Réponses

  • muqaddarmuqaddar Administrateur
    novembre 2012 modifié #2
    J'ai vu ça aussi. Je n'ai pas tout saisi au "principe".

    Il sera intéressant de tester.



    J'ai pigé qu'on codait en objective-C côté serveur, mais je demande à  voir comment marchent les interactions HTTP, et surtout comment est fabriquée l'interface ? Il faut quand-même faire du HTML (pas d'intérêt donc) ou il est généré à  partir de l'objective-C côté serveur ?
  • Si j'ai bien compris, tu fais une app Mac que tu heberges chez eux.

    Quand une requete http arrive sur ton domaine, ils transforment la requete en dictionary (j'imagine en prennant les valeurs du header http et les valeurs de l'url). Ton app reçoit le dictionary (via la ligne de commande ?) et réponds par un dictionary (pas du json, ni du html).

    Je pense que le dictionary en réponse est renvoyé sous forme de json mais ce n'est pas précisé.



    D'après les exemples, il ne semble pas possible de recevoir ou de renvoyer des données dans les requêtes (donc pas de download ou d'upload, ce qu semble être une grosse limitation quand même).
  • up

    Alors ça n'intéresse personne de faire du codage côté serveur en objective C ?

    Serait-ce une fausse bonne idée ?



    Ou les dev Objective C sont-ils déjà  suffisamment bon en php et/ou ruby ?

    Ca porte malheur d'utiliser un langage compilé côté serveur ?
  • CéroceCéroce Membre, Modérateur
    Je t'avoue que la démarche me laisse perplexe.

    ObjC est un langage qui essaie de trouver des compromis entre la proximité avec la machine (pour avoir un code rapide) et l'expressivité.



    Ce compromis n'a pas de sens de sens dans le contexte d'un serveur. L'expressivité est reine. Si c'est trop lent, on prend un serveur plus rapide, ou on travaille les algorithmes. Au pire, on peut programmer certaines routines en langage C.



    Programmer un serveur en ObjC, c'est vraiment pour les gens qui ne veulent pas faire l'effort d'apprendre un nouveau langage. Des gens qui seront coincés chez un seul fournisseur de service.
  • 'Céroce' a écrit:


    ObjC est un langage qui essaie de trouver des compromis entre la proximité avec la machine (pour avoir un code rapide) et l'expressivité.

    Ce compromis n'a pas de sens de sens dans le contexte d'un serveur. L'expressivité est reine. Si c'est trop lent, on prend un serveur plus rapide, ou on travaille les algorithmes. Au pire, on peut programmer certaines routines en langage C.




    Dans ce cas je n'emploierais pas l'expression "avoir du sens". C'est comme si tu disais cela n'a pas de sens de faire de la culture local. C'est vrai, si j'ai besoin d'une tomate, j'ai qu'à  prendre ma voiture pour aller à  l'hypermarché qui a fait venir des tomates d'Espagne par camion, plutôt que d'aller voir le maraicher du coin.

    C'est juste que c'est la solution plus facile et la plus économique au point où on en est. Pas celle qui a du sens.



    Aujourd'hui, enfin tant que l'énergie coulera à  flot et que le serveur sera immobile, c'est plus facile de rester sur un modèle où on augmente les perfs de la machine plutôt que de rendre le soft plus efficace. D'autant qu'on y gagne en coût de développement puisque le soft est "plus facile" à  produire.

    C'est une question d'équilibre entre coût de l'énergie et coût de développement.



    L'objective C est un langage idéal pour le mobile grâce à  son compromis entre performances et expressivité. Il permet d'obtenir un code lisible et moderne, tout en conservant l'énergie (la batterie !) des mobiles.

    Ce qui est moins évident avec des langages comme C#, java ou C/C++.



    Sur le serveur, la consommation énorme d'énergie commence à  poser des problèmes (au moins médiatiques) donc je pense que cela peut avoir du sens d'adopter des langages plus proche de la machine. Il faut "juste" que se produise un déclic comme l'iPhone dans la téléphonie mobile.



    D'autre part, quand tu dis "on prend un plus gros serveur", tu simplifies un peu la tâche. C'est en fait assez compliqué de monter en charge. Ca s'improvise pas, c'est un métier qui n'est pas plus facile que de faire de l'objective C.


    'Céroce' a écrit:


    Programmer un serveur en ObjC, c'est vraiment pour les gens qui ne veulent pas faire l'effort d'apprendre un nouveau langage.


    Je ne suis pas d'accord. C'est une question d'inertie de l'industrie, pas des gens. Il y a du code existant, des habitudes, des méthodes éprouvées, des gens déjà  formés, des hébergeurs qui veulent pas se poser de questions.

    C'est cela qui freine un éventuel changement pas les gens. Au contraire, les développeurs adorent apprendre des nouveaux langages.




    'Céroce' a écrit:


    Des gens qui seront coincés chez un seul fournisseur de service.




    C'est LE gros problème. C'est l'inertie des hébergeurs. Déjà  le passage à  ruby, c'est pas gagné pour les amateurs.

    Deuxième gros problème, il n'y a pas de framework libre.

    Troisième problème, c'est limité aux Mac.
  • 'Céroce' a écrit:


    Programmer un serveur en ObjC, c'est vraiment pour les gens qui ne veulent pas faire l'effort d'apprendre un nouveau langage. Des gens qui seront coincés chez un seul fournisseur de service.




    C'est sur, à  l'époque ou NeXT éditait WebObject en Objective-C les places boursières s'en servait juste par ce qu'ils ne voulaient pas apprendre Java :-)



    De mon point de vue un langage seul n'est rien, tout dépend de l'API. Java avec tout leur SDK Entreprise bien lourd, on sait ce que ça donne, du Java avec le SDK WebObject c'est pas la même...



    Objective-C en server side ? Tout dépend comment c'est monté et quels SDK sont dispo, si on a un truc à  eux qui sort de nul part ça sert à  rien, si on a du GSWeb (pendant libre de WebO vers ObjC dépendant de GNUStep) ça peut être environs intéressant, et si on a un serveur OS X avec le vrai framework Foundation la c'est carrément intéressant car c'est quelque chose qui a de l'âge, qui a bien évolué et qui n'a plus ses preuves à  faire (on l'a vu avec la simplicité de dev sur iOS vis à  vis d'Android dès les premières versions).
  • FKDEVFKDEV Membre
    décembre 2012 modifié #8
    C'est hébergé sur des mac mini, ils mettent justement en avant la possibilité d'utiliser les framework du Mac.

    Ils donnent des exemples de reconnaissance de visages dans des images, génération de pdf, geolocalisation.
  • 'FKDEV' a écrit:


    C'est hébergé sur des mac mini, ils mettent justement en avant la possibilité d'utiliser les framework du Mac.

    Ils donnent des exemples de reconnaissance de visages dans des images, génération de pdf, geolocalisation.




    Donc ça peut être très intéressant. Reste à  voir comment est fait leur connecteur HTTP. Est-ce qu'ils ont écris un module Apache qui passe la main à  un API ObjC ? ça serait très propre mais aussi très gros comme boulot...



    Si c'est un simple CocoaHTTPServer en front avec un packaging simplifiant toute la partie HTTP, faut voir ce que donne la stabilité du tout en cas de monté en charge...



    En allant plus loin, la question se pose de la gestion des sessions, des cookies, des méthodes HTTP pour supporter du DAV, des WebSocket, etc.



    Bref, le principe peut être très très bon, mais ils sont trop vague sur leur techno pour le moment.
  • FKDEVFKDEV Membre
    décembre 2012 modifié #10
    'yoann' a écrit:


    Donc ça peut être très intéressant. Reste à  voir comment est fait leur connecteur HTTP. Est-ce qu'ils ont écris un module Apache qui passe la main à  un API ObjC ? ça serait très propre mais aussi très gros comme boulot...




    En fait c'est assez simple de faire le lien via le protocole FastCGI. Il existe une librairie FastCGI en C qu'il est possible d'integrer à  un executable objective C pour recevoir les requetes web et répondre.

    J'ai deja fait une maquette avec le serveur web apache d'OSX, c'est pas tres compliqué (et je ne suis pas un pro de la config. Apache). L'avantage avec FastCGI c'est que l'executable reste en memoire entre chaque requete, ce qui simplifie un peu la gestion des sessions.

    L'avantage du serveur web apache c'est qu'on peut récupérer le legacy code php et le faire cohabiter avec de l'objective C.



    Le probleme c'est effectivement qu'il manque un framework sympa en objective C pour gerer les objets usuels du côté serveur (requetes, reponses, session).



    Je pense que toute tentative de framework proprietaire accouplé à  un hebergeur unique est voué à  l'echec. Déjà  que c'est assez risqué de miser sur de l'Objective C pour une solution web, si en plus on est dépendant d'un seul hébergeur, cest pas possible.



    J'aimerais bien croire à  cette architecture, mais je pense que les planètes ne sont juste pas encore alignées pour que ça décolle.
  • 'FKDEV' a écrit:


    Le probleme c'est effectivement qu'il manque un framework sympa en objective C pour gerer les objets usuels du côté serveur (requetes, reponses, session).



    Je pense que toute tentative de framework proprietaire accouplé à  un hebergeur unique est voué à  l'echec. Déjà  que c'est assez risqué de miser sur de l'Objective C pour une solution web, si en plus on est dépendant d'un seul hébergeur, cest pas possible.



    J'aimerais bien croire à  cette architecture, mais je pense que les planètes ne sont juste pas encore alignées pour que ça décolle.




    Bah le framework il existe, c'est GSWeb... Mais il est vieux, il avancerait bien mieux si les CocoaHTTPServer et autre Objective Cloud travaillaient sur un projet commun plutôt que chacun dans son coin...
  • J'ai regardé les sources de GSWeb que tu avais mentionnées dans un autre post et je n'ai pas trop accroché.

    En plus il faut compiler un module spécial pour apache. Je préfère l'approche via fastCGI qui requiert un minimun de config et qui peut s'adapter facilement à  d'autres serveur genre nginx.



    Dans les framework, il y a aussi bombax qui repose sur l'intégration de fastCGI. Les sources sont là  : http://code.google.com/p/bombax/.

    C'est un produit lancé début 2010 et qui s'est arrêté net au printemps 2010.



    Si j'ai le temps, j'essaierai de poster ici la maquette que j'avais faite il y a quelques mois.
  • 'FKDEV' a écrit:


    J'ai regardé les sources de GSWeb que tu avais mentionnées dans un autre post et je n'ai pas trop accroché.

    En plus il faut compiler un module spécial pour apache. Je préfère l'approche via fastCGI qui requiert un minimun de config et qui peut s'adapter facilement à  d'autres serveur genre nginx.




    Normal GSWeb est basé sur les spec de WebO 5.0 si je me souviens bien, c'est des spec qui datent de 2000 grosso modo. ça a bien vieilli aujourd'hui, mais le reste de la lib est un très bonne base pour refaire quelque chose aujourd'hui. Simplement il y a un gros travail de réécriture pour qu'il soit plus dépendant de GNUStep mais uniquement Foundation, et qu'il soit un peut plus récent en intégration.
  • FKDEVFKDEV Membre
    décembre 2012 modifié #14
    Pour mémoire. Marche à  suivre sur Lion pour faire un programme FastCGI:



    ==Config Apache:

    *Télécharger les sources du module fastcgi pour Apache

    http://www.fastcgi.c...-current.tar.gz

    *Compiler et installer le module mod_fastcgi
    [font=courier new,courier,monospace]sudo apxs -n mod_fastcgi -i -a -c mod_fastcgi.c fcgi_buf.c fcgi_config.c fcgi_pm.c fcgi_protocol.c fcgi_util.c[/font]



    Je ne me souvenais pas avoir fait ça sous Snow Leopard, le module était peut-être inclus...




    *Vérifier si le chargement du module fastcgi est bien dans /private/etc/apache2/httpd.conf

    [font=courier new,courier,monospace]LoadModule fastcgi_module libexec/apache2/mod_fastcgi.so[/font]

    *Vérifier que les extensions fcgi sont associées au handler fastcgi :

    [font=courier new,courier,monospace]AddHandler fastcgi-script .fcgi [/font]



    *Placer votre executable dans [font=courier new,courier,monospace]/Library/WebServer/CGI-Executables[/font]

    Cela semble être le répertoire configuré par défaut sur Mac, sinon vérifier dans la config. Apache.

    *Activer Apache (settings>Partage>Partage Web ou [font=courier new,courier,monospace]sudo apachectl start[/font])



    ==Créer un executable intégrant fastCGI.

    *Télécharger la lib fastcgi : [font=courier new,courier,monospace]http://www.fastcgi.c...ist/fcgi.tar.gz[/font]

    *Compiler (./configure, make, make install)

    *Renommer le résultat de compilation libfcgi.la en libfcgi.a

    (là  c'est sans doute pas la bonne manière de faire pour référencer la dylib compilée et installée juste avant mais j'avoue mon ignorance image/rolleyes.gif' class='bbc_emoticon' alt='::)' /> ).

    *Faire un projet ligne de commande dans Xcode, l'executable doit avoir l'extension .fcgi si on suit la config Apache ci-dessus

    *Inclure le .a, compiler, copier dans /Library/WebServer/CGI-Executables





    Je joins mon projet Xcode.

    Des instructions un peu plus détaillée sur ce blog pour la compilation des mod et lib fastCGI.

    http://spointeau.blo...-os-x-lion.html
  • Les légions de Mac sont en route pour envahir les data-center :

    http://www.mac4ever.com/actu/75940_insolite-il-a-cree-une-baie-de-160-mac-mini
Connectez-vous ou Inscrivez-vous pour répondre.