eBrainPool Messaging System

Getting back to what is the kind of communication happening between two eBrainPool clients. When they discover each other, and know the route to connect to each other, how do they exchange information?

Background Reading: Our Earlier post, Workflow Sketch, how it fits together (the exact workflow is now updated), and Under the Hood we now have an updated architecture, but they should be a good starting point if you need a refresher

It only uses the command line (exec) executable from the *.desktop spec file right now. We would like however to send the appname, and handle arguments too. Perhaps a comment, or description might be useful.

The bug filed on the same is in our 'sting (bug) report'

for those who are late, we have started to call bugs 'stings' in reference to what we affectionately refer to as Beehive Computing -- yes, I know, a sad joke, but have a heart, we have had our heads so deep in code these past few years, this is only fun we have, honest!

Currently the concept code has carried over, and is a simple colon separated string like . We have always intended to replace this with something more robust and flexible.

Evaluating using Apache Thrift for this A Special thanks to Facebook, for donating this code to the Apache Foundation

Put very simply, this is a cross language code generation engine, which will allow us to build a servers and clients, for the various supported languages, based on the protocol we define. Yes it is as yummy as it sounds. I am having a blast working with it.

It seems to be able to generate c code, which was a factor in choosing this over protocol buffers, License being the other one. Not much in terms of example code and documentation yet, and the closest example / tutorial is C++, but I did notice a c_glib variant, it seems new. I am working through it right now.

As for the protocol I am proposing we use, looking to define three parameters for exchange of data between the ebrainpool clients.

  1. Application Name
  2. Application Command line
  3. Comments (maybe we use this as a description, or send the arguments separately? will need to evaluate this further)

I am currently in the process of writing together a server & client code, just a single threaded version to start off, but there is the option of using Threaded buffer transports. right now I just need to evaluate the status of thrift in using the protocol defined above. There is the possibility of backword compatible versioning, so this can be upgraded to a more appropriate variant as we continue.

from there, once happy, it should be a fairly simple integration of the same example code, into the eBrainPool code (Famous Last Words ? -- Lets hope not), more on this to follow, will keep updating as things progress.

Previous Post Next Post