API sexy

[entwanne]

Il faudrait répertorier ici les éléments qui feront de notre API une API sexy. En voici déjà quelques-uns:

• Signaux/slots → Si on reste là-dessus pour le hook des modules, ça peut rendre vraiment très bien
• Très modulaire → Tout est module, ça permet d'avoir une architecture propre et cohérente
• Surcharge d'opérateurs → On vient de tomber sur un code où ils faisaient des packet.head.setHeader("Content-Encoding", "x-gzip"); alors que je pense qu'on est tous d'accord pour dire qu'un packet.headers["Content-Encoding"] = "x-gzip"; est préférable

À vous

[nutsi]

Oui, pour les signaux et slots. La seule chose c'est qu'il faudra pas necessairement ce baser sur ce que j'ai fais (src/Signal.hpp).

De plus auras-t'on besoin d'un type de retour? Si, oui il faudra modifier le StockCallback (src/bind/Caller.hpp), qui d'ailleurs n'a pas grand chose a faire dans Caller.hpp, je vais m'occuper dans l'apres midi de refaire un .hpp pour sortir bind et cette classe de Caller.hpp.

Gros +1 pour la surcharge d'operateurs. Tu as le lien d'ou tu as vu cela? En parlant de surcharge, j'etais entrain de penser que par exemple on pourra forcer l'implementation de << et de >> pour les modules. Ainsi, les modules n'auront plus qu'a informer via un signal qu'il y quelque chose a read, et apres plus qu'a appeler la bonne surcharge. (enfin, faudra trouver un moyen pour que l'on soit tenu informer de ce qu'il a lire dans un module. c-a-d lorsqu'il aura finit son traitement?

Il faudra aussi avoir une bonne architecture pour le projet, j'entend par la, que tout ne soit pas fait n'importe comment. Par exemple pour le moment dans thread on a thread/linux et thread/windows avec des headers qui ce repetent. Donc c'est pas cool. Il faudrait p-e avoir un repertoire /src et un /include, bien entendu dans /src il pourra y avoir des headers qu'un utilisateur n'aura pas besoin de connaitre.

[entwanne]

Pour le lien, il s'agit de: http://code.google.com/p/zia-epitech-2013-gavory-f/wiki/HTTPPacket Je pense aussi que l'implémentation de certains opérateurs sera très importante: [], <<, >>, () dans une moindre mesure (si on arrive à lui trouver une utilisation kewl)

[slashdevsda]

et une archi sous forme de callbacks de modules, appelés a la chaine au bon moment ? (apache) genre:

on_connect[] = { module1_on_connect; module2_on_connect; ... }

on_close[] = {...}

on_receive[] = {...}

on_send[] = {...}

on_preprocessing[] = {...}

on_postprocessing[] = {...}

ces tableaux étants gérés dynamiquement ? c'est bien plus simple qu'un système de signal, et aussi efficace. et avec Bind(), ça roule.

[nutsi]

En faite, ce que Thomas veux dire c'est que l'on peux avoir a plusieurs niveaux besoin d'un meme module. Et que du coup, on peux faire un tableau de callback a appeler pour chaque niveau (sous-entendu un tableau par niveau). Et dans la conf des choses du genre:

nom_du_module suivis_des_niveaux_auquels_il_intervient

[entwanne]

C'est moins beau je trouve

[slashdevsda]

oui, ici c'est moins beau, mais c'est ce qui tournera en "background". Rien ne nous empeche d'abstraire ça de façon sexy <3 !