More, more, more!

As it is, the time is constantly more limited. I need more time, lots and lots of more time (and I need to stay away from the stargate episodes ^^)

In the PySM story, I’ve been assigned with developing the system core on the system. That core will (or should) organize the processes, system resources, communication between other cores, etc… I’ve thought some things through, but as it is, I’m stuck. Writing this might open op some items (and spice up this boring blog)

Communication!

For starters. The entire PySM packet will be designed from the ground up to be decentralized and preferably 100% scalable. Albeit the scalability isn’t the easy, nor the hard part. Thanks to the decentralization, scalability will rise bunch already.

So with decentalization comes communication, otherwise the different parts would be nothing more but meaningless pieces of code fooling other parts :D

After a little while of thinking, we decided to go with XMPP for communication. We know it’s not meant to be a protocol for managing _anything_, but the stanza system works in our advantage, and being capable of seeing “who” is online would get the front-end to see whether or not certain systems are online, etc… Basically, it gets a bunch of the work (thinking-wize) of the grid.

Downside is that we want (or would like to) create a 100% python project. The clients (which would reside in all cores) have got libraries in sleekxmpp, pyxmpp, etc… Choice all the same, and a choice we will make.
The server however we don’t have any libraries that we know of. So we figured we’d create one of our own ^^

Long live insanity

So, bottomline, that server would reside in the part I’m assigned with. It’ll basically become very hard. And I hope I’m up to the challenge :)

Starting to write an XMPP server is not simple. Although there’s a lot of projects online, I figured I’d stay away from that code as much as possible (most of it seems to be C and Java anyway) Working up from the RFC seems to be the best option imho.
I rather call myself idiot and insane for doing so, but I can’t help myself.

Basics

To start, we don’t want to create an entire XMPP server to start with. We only need a server to suffice our needs, being (for starters) basic query / response communication, as well as presence stanza capability. It’s going to be really cool, but identifying users will be yet another story. Perhaps we’ll go configure those systems a bit.

Not that I want to explain the entire XMPP protocol, but since it works the way it does, I’m thinking of using a simple [program_name]@[ip]/[configured_string] , I figured that would identify every program to be an ip, and the string can be used to tie rights, possibilities, etc… to users. To enable more scalability, we shouldn’t be using ip’s, because those can change, and when they do, there should not be a need for reconfiguration. The only configuration should be when the system is deployed, and even then configs should be dummy-size easy :)

Therapy

And to close in totally unrelated matters. I find blogging like this really relaxing. Gets my thoughts together by putting them randomly on a post (and the best thing is I won’t ever lose those thoughts… Ever…)

So, thanks for the session, and I’ll come over on a more regular meeting preferably :)