I'm also thinking about dropping the router component at all and connecting all services with 0MQ bus. Pushing NADs directly to bus would save on unneeded serialization/deserialization via XML.
Also, dropping router would be awesome, I believe thats the only component that can't be part of a mesh network? A really good goal to go after could be to make sure jabberd2 scales by adding more nodes in the network.
Since the router has to route all packets - it becomes a bottleneck fast
in fact the default topology for "bus" is everyone-connects-everyone :)
another thing I am tempted to do is throw away sm modules implemented in C and do them in JavaScript using http://duktape.org/ interpretter
this would enable the host of experimentation in XEP area jabberd2 was designed to support
as it is now, devs are afraid of writing SM modules as C is too incomprehensible for them
but this leaves the question of mapping XML data of XMPP to JS objects... I've been researching this for some time now, and I think MicroXML ( https://dvcs.w3.org/hg/microxml/raw-file/tip/spec/microxml.html ) mapping is the way to go
It even allows for preserving XML namespaces to JS objects.
I wrote a lot of C code add-ons to SM for my startup :) It's pretty straight forward already. Perhaps the one thing that could be improved on for sure is the XML capabilities. Haven't really looked but wondering if there are other libraries to make it easier. I would probably want to stay away from JS in the current codebase. Might be a mighty fine project in node.js - it needs a good server anyways :)
Or if you are interested, an erlang version? :)
Hi!
sm modules implemented in C and do them in JavaScript using http://duktape.org/ interpretter
Do you mean to rewrite SM in JS completely or just implement high-level logic only keeping low-level (sx, sasl) in C?
sm as it was implemented in C with all RFC required logic. but all XEPs are currently loadable modules to SM... so, let's have them in javascript for easier experimentation and catching up with all the changes inroduced by XSF
@eagafonov I'm ditching the router protocol. There will be a common message bus with anyone interested able to push a message onto and react to a message on bus. no router intermediary
and yes - processes written in different languages are welcome to connect to the bus :)
BTW I was trying to implement self-organizing mesh network of components using 0MQ.
It was and RnD to implement distributed router for jabberd2 :-)
So you your idea looks like an integrating part of distributed "router" into each component.
in simplest form is is everyone-to-everyone
but you can construct hub nodes using raw sockets
and have a star, tree, or whatever you like
it is not self-managing, and requires administrator setup
One thing that should be maintained is compatibility with existing C sm modules (I have a lot :smile:). And also, I have several cases where I am sending a newly packet directly to router rather than have it be processed via SM. So if we remove the router, need a way to enable this scenario.
nyah... scratch that... doubles maintenance
as long as the NADs are passed around - it should work I believe
and that way one could disable that module in case they don't want to compile in JS support
I just pushed preliminary daemon code of "jabberd3" https://github.com/jabberd2/jabberd2/tree/ashnazg
Is anyone interested in taking a look, whether is this something you would like jabberd evolve into?
hey, if anyone has any remote remote , designer, DevOps or Sysadmin jobs they can post them at http://webwork.io
TravisCI is cool. It took me just 7 attempts to create a passing build configuration. And 1 push to fix a Debian-still-using-stone-age-software specific issue. ;-)
still cooll.... https://travis-ci.org/jabberd2/jabberd2 is preeeeeetyyyyy :D
what do you think?
did anybody test support of XEP-0191 in jabberd2 ... I have here 2.4.0, blocking list full of IDs (http://paste.fedoraproject.org/449280/14763509/), but messages from these servers still get through? ????
I was wondering if anyone know a XMPP websocket library, written in C#
