heu non, une comparatif complet a été effectué mais peu sont dédié embarqué en respectant ses contraintes.
Sans les décribiliser, ce sont aussi souvent de gros développement avec une API qui vont au déla d'un usage embedded.
Abus ne s'est pas voulu tout remplacer ou réinventer mais plutôt founrnir un tiny librairie qui certes fait un minimum de choses mais qui le fait bien en tenant compte de ses contraintes.
he bien c'est un développement alternatif similaire qui s'est avant tout inspiré de dbus.
il n'y a certes pas toutes fonctionnalités de part sa jeunesse mais cela à pour intérêt d'offrir une alternative viable puisque ce bus est déjà utilisé avec succès dans un développement commercial.
j'ai plus pas mal de fois des projets embarqué qui se débrouillais assez bien avec du bytecode, un garbage collector intégré, et toute la panoplie d'un langage objet.
Bref, abus n'a pas été écris en python mais pourra être utiliser dans ce langage tout en étant écrit en langage C, langage permettant une gestion de la consommations mémoire moindre.
Elle le peut tout à fait mais ce sont avant tout des contraintes que l'on retrouve dans l'embarqué et après comme je l'indiquait c'est transposable aux desktops.
Je voulais préciser que ce développement ne se voulait pas décribiliser DBUS mais plutôt d'offrir une alternative aux plateforme GNU/Linux embarqué pour qui chaque ressources cpu, mémoire, IT comme les changement de contexte, accès aux I/O, …. compte.
A ce jour Abus est livré sous la forme d'une librairie dynamique & statique incluant des fonctionnalités json. Le développement offre aussi une cohérence avec pkgconfig via des métadata (abus.pc).
Si des développeurs sont intéressés pour collaborer au développement ou bien des utilisateur pour augmenter le nombre de cas d'utilisation.
Sinon, pour répondre à la connexion sur réseau local, comme je le précisait, le but est justement d'avoir cette orientation embarqué ce qui a été la contrainte la plus importante (pas de daemon, faible consommation de CPU & mémoire, moins de changement de contextes, …
Une passerelle est cependant possible comme je le précisait via lighttp et un plugins fcgi via des échanges HTTP(s)/json RPC.
Abus a vu démarré son développement en fin d'année dernière et sort aujourd'hui dans une version stable.
[^] # Re: Licence
Posté par thierryg35 . En réponse à la dépêche A-Bus, un autre bus dédié GNU/Linux embarqué. Évalué à 1.
heu non, une comparatif complet a été effectué mais peu sont dédié embarqué en respectant ses contraintes.
Sans les décribiliser, ce sont aussi souvent de gros développement avec une API qui vont au déla d'un usage embedded.
Abus ne s'est pas voulu tout remplacer ou réinventer mais plutôt founrnir un tiny librairie qui certes fait un minimum de choses mais qui le fait bien en tenant compte de ses contraintes.
[^] # Re: Licence
Posté par thierryg35 . En réponse à la dépêche A-Bus, un autre bus dédié GNU/Linux embarqué. Évalué à 2. Dernière modification le 23 mars 2012 à 10:44.
en fait il avait récemment changé de licence pour prendre la lgpl.
j'aurais préféré BSD ou MIT qui est plus permissive.
cela permet au moins de linker avec abus sans contamination.
[^] # Re: 0MQ ?
Posté par thierryg35 . En réponse à la dépêche A-Bus, un autre bus dédié GNU/Linux embarqué. Évalué à 1.
he bien c'est un développement alternatif similaire qui s'est avant tout inspiré de dbus.
il n'y a certes pas toutes fonctionnalités de part sa jeunesse mais cela à pour intérêt d'offrir une alternative viable puisque ce bus est déjà utilisé avec succès dans un développement commercial.
[^] # Re: Bindings Python ?
Posté par thierryg35 . En réponse à la dépêche A-Bus, un autre bus dédié GNU/Linux embarqué. Évalué à 1.
j'ai plus pas mal de fois des projets embarqué qui se débrouillais assez bien avec du bytecode, un garbage collector intégré, et toute la panoplie d'un langage objet.
Bref, abus n'a pas été écris en python mais pourra être utiliser dans ce langage tout en étant écrit en langage C, langage permettant une gestion de la consommations mémoire moindre.
[^] # Re: Petite question
Posté par thierryg35 . En réponse à la dépêche A-Bus, un autre bus dédié GNU/Linux embarqué. Évalué à 2.
Elle le peut tout à fait mais ce sont avant tout des contraintes que l'on retrouve dans l'embarqué et après comme je l'indiquait c'est transposable aux desktops.
[^] # Re: Petite question
Posté par thierryg35 . En réponse à la dépêche A-Bus, un autre bus dédié GNU/Linux embarqué. Évalué à 3.
Je voulais préciser que ce développement ne se voulait pas décribiliser DBUS mais plutôt d'offrir une alternative aux plateforme GNU/Linux embarqué pour qui chaque ressources cpu, mémoire, IT comme les changement de contexte, accès aux I/O, …. compte.
A ce jour Abus est livré sous la forme d'une librairie dynamique & statique incluant des fonctionnalités json. Le développement offre aussi une cohérence avec pkgconfig via des métadata (abus.pc).
Si des développeurs sont intéressés pour collaborer au développement ou bien des utilisateur pour augmenter le nombre de cas d'utilisation.
[^] # Re: Petite question
Posté par thierryg35 . En réponse à la dépêche A-Bus, un autre bus dédié GNU/Linux embarqué. Évalué à 4.
il y en a pas mal et sans en faire un listing complet, il y a Corba, dbus, com+, dcom, DEC, ICE, XML-RPC, …
http://en.wikipedia.org/wiki/Remote_procedure_call
[^] # Re: Comment ça marche ?
Posté par thierryg35 . En réponse à la dépêche A-Bus, un autre bus dédié GNU/Linux embarqué. Évalué à 2.
Sinon, pour répondre à la connexion sur réseau local, comme je le précisait, le but est justement d'avoir cette orientation embarqué ce qui a été la contrainte la plus importante (pas de daemon, faible consommation de CPU & mémoire, moins de changement de contextes, …
Une passerelle est cependant possible comme je le précisait via lighttp et un plugins fcgi via des échanges HTTP(s)/json RPC.
Abus a vu démarré son développement en fin d'année dernière et sort aujourd'hui dans une version stable.
[^] # Re: Comment ça marche ?
Posté par thierryg35 . En réponse à la dépêche A-Bus, un autre bus dédié GNU/Linux embarqué. Évalué à 2.
Oui je confirme que ABUS est orienté embarqué pour un usage local via des sockets UNIX.