Ali's JSON-RPC Framework
AliGator
Membre, Modérateur
Bonjour à tous 
Ayant déjà eu plusieurs fois besoin d'un framework JSON-RPC et n'ayant jamais trouvé mon bonheur (le seul existant à ma connaissance est DeferredKit mais il est plein de fuites mémoire et pas super bien foutu ni ne respecte les conventions de nommage...), j'ai décidé vu mon besoin pour un projet de faire mon propre framework
Je compte donc le partager avec la communauté d'ici peu (genre article dans le blog), mais avant l'idée étant que vous me disiez aussi ce que vous en pensiez et si vous voyez des trucs à améliorer (dans le code ou dans l'architecture logicielle) pour le fignoler.
Donc en attendant de publier le code, et pour vous mettre l'eau à la bouche, vous trouverez ci-joint la doc Doxygen de mon framework, contenant également une page de présentation du framework et une page donnant un exemple type d'utilisation. (Vous pouvez ouvrir la documentation dans votre navigateur (fichier HTML qui ouvre le docset dans votre browser) ou ouvrir le DocSet dans Xcode directement, au choix)
Je suis déjà preneur de vos retours même rien qu'à partir de la doc... donc vous souhaite bonne lecture
Ayant déjà eu plusieurs fois besoin d'un framework JSON-RPC et n'ayant jamais trouvé mon bonheur (le seul existant à ma connaissance est DeferredKit mais il est plein de fuites mémoire et pas super bien foutu ni ne respecte les conventions de nommage...), j'ai décidé vu mon besoin pour un projet de faire mon propre framework
Je compte donc le partager avec la communauté d'ici peu (genre article dans le blog), mais avant l'idée étant que vous me disiez aussi ce que vous en pensiez et si vous voyez des trucs à améliorer (dans le code ou dans l'architecture logicielle) pour le fignoler.
Donc en attendant de publier le code, et pour vous mettre l'eau à la bouche, vous trouverez ci-joint la doc Doxygen de mon framework, contenant également une page de présentation du framework et une page donnant un exemple type d'utilisation. (Vous pouvez ouvrir la documentation dans votre navigateur (fichier HTML qui ouvre le docset dans votre browser) ou ouvrir le DocSet dans Xcode directement, au choix)
Je suis déjà preneur de vos retours même rien qu'à partir de la doc... donc vous souhaite bonne lecture
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Je suis entrain de bosser sur une lib "PLIST-RPC" pour moi et le dialogue avec un web service Apple. Si tu publie les sources du tiens je vais attendre un peut pour regarder de plus près tes choix d'implémentation, surtout pour ce qui est du [service.proxy echo:[NSArray arrayWithObject:@Hello there]].
Au passage, ton fichier HTML est un lien cassé vers le DocSet, les liens fait par le finder utilise des chemins absolu. Utilise le terminal et la commande ln depuis ton dossier de doc pour faire un lien symbolique à partir de chemin relatif.
@yoann & @olof : Oui en fait j'avais fait un lien symbolique Unix à la base avec "ln", sauf que quand tu double-cliques dessus, c'est le fichier (l'entrée i-node Unix) représenté par le lien symbolique (donc le fichier quo'n a double-cliqué quoi) qui s'ouvre et non l'original. Et la conséquence de ça c'est que du coup tous les chemins relatifs dans le HTML sont cassés, il ne trouve pas les images ni les CSS utilisés dans la documentation Doxygen.
Du coup j'ai fait un alias pensant que ça allait "tenir" en le transférer sur une autre machine par ZIP, mais j'avais un doute justement... vous venez de me confirmer que ça ne marche pas non plus donc.
Je vais p'tet essayer un vrai lien symbolique (ln -s) car je crois que j'avais fait un lien dur (ln). Et puis si ça marche pas je ferai un HTML qui fait une redirection, ou sinon bah vous avez qu'à ouvrir le docset, na
Alors qu'avec un lien symbolique créé en passant le chemin relatif de l'original (et pas le chemin complet), non seulement le lien devrait marcher où que vous décompressiez le ZIP chez vous même si vous n'avez pas la même arborescence de fichiers.
Enfin bref, je changerai ça en mieux pour le truc de l'alias sans doute ce soir...
Revenons à l'objet de ce post quand même
Genre exemples pratiques :
C'est ce qui explique pourquoi après ces expériences dans d'autres projets, j'ai du coup fait la gestion des erreurs ainsi...
(Bref, causons un peu code et archi logicielle, mince, c'est quand même le plus intéressant
Mon framework JSONRPC est donc dispo ici.
A vos tests et commentaires !
Merci de ton premier retour.
Alors :
1) Si j'ai géré ça comme ça avec possibilité de préciser le delegate et callback pour chaque requête c'est parce qu'en pratique en général je ne crée qu'un JSONRPCService app-wide (même habituellement dans mon singleton qui expose mon interface/API spécifique au webservice utilisé dans l'appli) et que j'appelle ensuite cette unique instance d'un peu partout de mes divers controlleurs... Du coup n'avoir qu'un seul delegate commun pour toutes les requêtes de mon appli est loin d'être arrangeant (sans parler des compare: à faire sur tes IDs€ en fait je l'avais prévu comme ça au début mais j'ai vite vu les limitations à l'usage.
2) Ceci dit même si ça n'apparaà®t pas clairement dans la doc et que je n'ai pas reverifié que ça marchait bien dans tous les cas, si je dis pas de bétises (je suis sur mon iPhone là j'ai pas mon mac sous la main ce WE) ce fonctionnement est possible (et s'il ne l'est pas c'est pas violent à coder sans bousiller l'archi logicielle) : si tu ne spécifies aucun delegate et selector sur le JSONRPCResponseHandler je crois qu'alors un message -methodCall:didReturn:error: est envoyé au delegate du JSONRPCService du coup... (ou au service directement ?) ...qui d'ailleurs en possède une implémentation par défaut (fallback) qui ne fait que loguer le résultat.
Après ça correspond pas pile poil à ce que tu veux -- d'autant qu'en fait je suis en train de me dire que je confond peut-être avec ma gestion d'erreurs -- et si tu peux bien récupérer l'ID de la requête (JSONRPCMethodCall::uuid) elle est générée automatiquement avant envoi donc c'est pas toi qui la définit.
Je verrai à mon retour si je peux pas + ouvrir cette autre possibilité d'utilisation, tel que c'est codé ça devrait être jouable de rajouter la possibilité de choisir son ID de requête soi même et utiliser le delegate du service s'il n'y en a pas sur le ResponseHandler pour les réponses comme c'est fait pour les erreurs.
Comme ça ça permettra de garder mon fonctionnement actuel ou de choisir le tien au choix :-)
Sinon autre possibilité c'est d'inclure la possibilité d'avoir un contextInfo, je ne l'ai pas vu dans la doc
Je regarde pour faire en sorte qu'il soit flexible et que yoann tu puisses l'utiliser tel que tu l'as décrit avec un ID retourné, un delegate commun (celui du JSONRPCService) et que tu gères du coup la réception en comparant l'ID.
L'idée étant pour toi yoann de pouvoir l'utiliser tel que je l'ai décrit dans le post juste au dessus, avec la récupération du uuid quand la requête est envoyée et la comparaison dans la méthode de delegué ; dans l'état actuel je n'utilise pas encore le delegate du JSONRPCService pour ça et je n'ai pas de nom de méthode générique dans le @protocol pour la réception de la réponse.
Alors ceci dit ça m'intéresse : c'est voulu d'avoir prévu ton "sharedDelegate" différent du "delegate" de ce même JSONRPCService ?
De plus, du coup comment tu récupères les réponses dans ce cas ? Tu spécifies bien quand même une callback / un selector ? Ou cette méthode est fixe (tu utilises un @protocol donc n'a pas le choix du nom de la méthode c'est toujours la même qui est appelée) ?
La property en question s'appelle responseHandlerDelegate en réalité. Je lui ai mis un nom à part pour que ce soit bien visible lors de l'utilisation que ce n'est pas un delegate utilisé par le service en lui même mais par les responseHandlers qui seront créés par la suite
En fait moi aussi je n'utilise que des @protocols formels habituellement.
Sauf que dans ce cas justement j'ai vu par la pratique que c'est pas forcément super... car tu peux appeler plusieurs méthodes en parallèle et il faut les différencier. D'où l'idée du handler.
Exemple type j'ai un écran (une UIView, associée à un UIViewController) avec plusieurs boutons dessus, chacun appelant une méthode d'un service JSON-RPC distant. Si le UIViewController est le delegate commun pour toutes ces méthodes, et que tu as un @protocol formel, autrement dit que c'est toujours la même méthode "methodCall:didReturn:error:" qui est appelée dans chacun des cas... Ben c'est pas simple de différencier quand c'est la réponse à ton appel JSON-RPC de "loginWithUser" ou "getMachinList:" ou "addMachinForUser:" etc. sur ton service.
Bien sûr, c'est faisable en fait très simplement : comme tu reçois l'objet JSONRPCMethodCall en paramètre, comme dans toute méthode de delegate bien faite (puisque comme toi moi aussi je commence la méthode du delegate par le nom du truc), tu peux récupérer "methodCall.methodName" pour comparer avec "-isEqualToString:" et donc faire des "if" de partout pour savoir de quelle réponse il s'agit.
Et après ? Bah soit tu mets alors le code pour gérer la réponse directement dans chaque branche du "if" concernéee, soit tu appelles une autre méthode, histoire de faire propre, pour séparer le traitement de chaque requête différente... Et là , pouf, on revient directement à mon cas où moi je précise directement la méthode à appeler...
Bref, le mieux de toute façon c'est d'avoir les deux possibilités et de laisser le choix d'utiliser l'une ou l'autre
Ainsi maintenant tu as le choix, soit tu as un delegate global sur ton JSONRPCService, soit tu définis un delegate de ton choix pour chaque appel (pour chaque JSONRPCMethodCall que tu envoies via les méthodes "callMethod..."), en précisant si tu veux un callback particulier pour chaque appel... ou en utilisant le callback générique "methodCall:didReturn:error:".
Et dans tous les cas, si tu as le même callback/selector pour récupérer les réponses diverses à différents methodCalls, tu peux faire des tests sur methodCall.methodName par exemple, ou sur methodCall.uuid, pour tester duquel il s'agit.
De toute façon je trouve ça plus propre, c'est plus logique que tout suive le même chemin, les erreurs internes (perte de cxn sur l'iPhone, etc) comme le résultat, c'est le même principe maintenant : si un delegate sur le JSONRPCResponseHandler, il est utilisé, sinon ça tombe sur celui du JSONRPCService.
PS : J'ai également mis à jour la doc et corrigé un petit memory leak au passage
Supporte maintenant JSON-RPC 1.1 (en plus de 1.0 et 2.0) : les classes JSONRPCService et JSONRPCService_v2_0 ont été fusionnées, de même que JSONRPCMethodCall et JSONRPCMethodCall_v2_0, et une propriété "version" remplace le tout dans la classe JSONRPCService et est à préciser maintenant dans le constructeur de JSONRPCService.
S'il y en a qui veulent tester ils sont les bienvenus : je n'ai pas eu l'occasion de trop tester tous les cas d'usage possibles (n'ayant pas bcp de WebServices 1.1 ou 2.0 sous la main ce soir) donc avec ce petit refactoring il y a peut-être des petites foirades que j'aurais laissé passer.
De même pour la doc elle commence à être sacrément fournie (tant le docset que le wiki sur github) du coup j'ai p'tet oublié de mettre à jour certains points, donc tout retour est bon à prendre.
Bon pour info j'ai dû oublier de pusher ma dernière correction sur github car d'après les retours d'Alex après avoir telechargé la dernière version il a 2-3 erreurs de compilation, que j'avais corrigées sur mon Mac pourtant.
Je tacherai donc de faire un push de ma dernière version ASAP.
Je me suis peut-être également emmêlé les pinceaux dans les tags puisque j'avais fait un tag GIT pour la v1.1, et j'en ai fait un autre pour la v1.2, mais apparemment Ale m'a dit que quand il a voulu télécharger ça lui a pris l'ancienne version par défaut? Comme si la HEAD était restée au stade de la 1.1? Je maitrise peut-être pas bien github de ce coté ?
Je ne suis pas sur d'avoir un accès réseau la semaine prochaine (car en déplacement), je vous tiens au courant pour ceux qui suivent ça !
EDIT :
Le FW a l'air OK maintenant. Je n'ai plus de messages d'erreurs.
- j'ai enlevé le tag 1.2 et refait un tag 1.2a. Ce tag correspond à la version 1.2 corrigée (cà d qui compile maintenant)
- J'ai testé en cliquant sur le bouton "Download source" sut github, ça m'a bien pris la dernière version
(j'ai juste pas réédité la doc pour mettre "1.2a" à la place de "1.2" dedans, hein
La prochaine update prévue traitera les erreurs HTTP (pour l'instant je suppose que le serveur me retourne toujours un "HTTP 200 OK" je teste pas le code de retour HTTP) en appelant [tt]methodCall:didFailWithError:[/tt].
NB : Il est possible que je renomme la méthode de protocole formel "[tt]initWithJson:[/tt]" en "[tt]initWithJsonObject:[/tt]" au passage, pour que ce soit plus parlant et porte moins à confusion : en effet cette méthode reçoit en paramètre un objet JSON déjà interprété (par SBJSON) en NSDictionary ou NSArray ou autre, et pas une NSString représentant la chaà®ne JSON non interprétée.
Je pars en déplacement cette semaine, je risque de ne pas être trop dispo de toute façon (à part depuis mon iPhone :P) donc les mises à jour ne viendront sans doute pas tout de suite. Ceci dit à part ce truc de codes d'erreur HTTP, je ne pense pas qu'il y aura de gros changements de prévus à court terme maintenant que le refactoring est fait
Sous quelle licence est publiee ton framework ?
D'ailleurs s'il y en a qui ont des conseils sur ce point, je suis preneur.
Ayant du mal à retrouver mes petits entre les licences GPL, Apache, BSD, CeCILL, etc., j'ai juste mis un "Copyright Notice" dans mon code, repris pour info de celui de SBJSON en fait, car il se trouve qu'il correspondait à mes attentes.
En gros : vous avez droit de l'utiliser librement, ainsi que de proposer des corrections et évolutions, mais l'auteur d'origine (en l'occurrence moi) ainsi que les mentions de la présente licence doivent toujours être repris et conservés
Après je ne sais pas s'il y a une licence "classique" / "usuelle" qui correspond à peu près à mes attentes de partages de code dans ce cas, j'avoue que je me suis un peu renseigné il y a peu pour regarder mais j'ai vite été perdu. Donc s'il y en a qui connaissent un peu le domaine...?
(Mais moi non plus je ne suis pas un expert dans le domaine)
Bonne recherche.
Pierre
J'avais aussi regardé justement du côté de tout ce qui dérive de GPL, mais entre GPLv2, GPLv3, BSD, Apache, CeCILL, et toutes les autres qui dérivent plus ou moins des licences GPL justement, c'est la jungle...
Je vais regarder de plus près BSD du coup, merci zoc. Faut que je regarde ce que cette licence pose comme restrictions, autorisations, obligations, etc.
Pour le moment j'ai utilisé le framework SBJSON, ça marche très bien et c'est bien plus rapide que le XML je trouve.
Par contre j'aimerai connaitre les différences entre ton projet Ali et celui que j'utilise.
Pourrais-tu m'éclairer s'il te plait?
Merci
Le project d'Ali, qui d'ailleurs utilise SBJSON, implémente RPC-JSON, c'est à dire un protocole d'appel de fonctions distantes, utilisé principalement par des "webservices". Très utile donc quand tu veux faire communiquer une application iPhone (ou Mac d'ailleurs) avec un webservice existant ou un webservice que tu implémentes toi même. Cela évite d'avoir à réinventer la roue coté iPhone à chaque fois...