by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Feb 07 2019 15:25
    YmrDtnJu commented #182
  • Jan 18 2019 13:03
    fauust commented #193
  • Jan 18 2019 13:02
    fauust commented #193
  • Jan 18 2019 07:03
    ottok commented #193
  • Jan 18 2019 07:01
    ottok commented #193
  • Jan 17 2019 22:04
    fauust edited #193
  • Jan 17 2019 21:49
    fauust opened #193
  • Jan 15 2019 14:50
    totalAldo edited #192
  • Jan 09 2019 16:14
    totalAldo opened #192
  • Jan 02 2019 10:49
    wolandtel opened #191
  • Dec 10 2018 11:20
    deep-42-thought opened #190
  • Dec 02 2018 03:23
    Neustradamus commented #170
  • Nov 26 2018 13:15
    greno4ka commented #163
  • Nov 01 2018 20:45
    smokku commented #189
  • Nov 01 2018 20:45
    smokku closed #189
  • Nov 01 2018 20:41

    smokku on jabberd-2.7.0

    2.7.0 release (compare)

  • Nov 01 2018 20:32
    smokku closed #176
  • Nov 01 2018 20:32

    smokku on master

    Return EAFNOSUPPORT on failed a… Updated NEWS (compare)

  • Nov 01 2018 20:31
    smokku closed #169
  • Nov 01 2018 20:22
    smokku labeled #182
Tomasz Sterna
@smokku
is there anything you would like to be included before the release?
Tomasz Sterna
@smokku
Guys, how do you feel about unifying all jabberd2 daemons to one? i.e. there would be just one 'jabberd' and whether it functions as a router or c2s or sm (or maybe all), you would select via a command-line switch.
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.
Shawn Debnath
@sdebnath
I support merging into one daemon - it reduces operation costs of monitoring and reporting on multiple with associated metrics etc.
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
Tomasz Sterna
@smokku
yes. it is be possible to construct a bus topology with 0MQ that there is no single point of failure
in fact the default topology for "bus" is everyone-connects-everyone :)
Shawn Debnath
@sdebnath
Yep - similar to distributed erlang which powers ejabberd. Would be awesome to have this!
Tomasz Sterna
@smokku
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.
Shawn Debnath
@sdebnath
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? :)
Eugene Agafonov
@eagafonov

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?

Eugene Agafonov
@eagafonov
It could go deeper: implement generic module in C (sx, tls) and any bindings to JS/Lua/Python/brainfnck to implement any logic on top of router protocol.
I've used python+twisted to implement module on top of router protocol.
Tomasz Sterna
@smokku
only XEP logic in JavaScript
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 :)
Eugene Agafonov
@eagafonov
As far as I know, 0MQ implement p2p communication or broadcasting. Is sounds like each component must connect to each other. It results in having some registry (just another point of failure) or implement something like DHT so any component will provide info to newcomers.
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.
Tomasz Sterna
@smokku
it really is up to deployment how to construct the bus topology
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
Shawn Debnath
@sdebnath
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.
Tomasz Sterna
@smokku
what about two SM implementations? old one using .so modules, new one using .js modules?
nyah... scratch that... doubles maintenance
Shawn Debnath
@sdebnath
Or fake it. Have a C "sm module" that then acts as the interface to the JS modules. It just fits into the existing pipeline
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
Tomasz Sterna
@smokku
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?
nodecraic
@webworkio
hey, if anyone has any remote remote , designer, DevOps or Sysadmin jobs they can post them at http://webwork.io
Tomasz Sterna
@smokku
Build #8 passed
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?
Tomasz Sterna
@smokku
Just released 2.4.0
Matěj Cepl
@mcepl
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? ????
sklv
@sklv
hi, out of interest does jabberd2 support omemo? i see omemo depends on pep, and mod_pep is in progress. despite that, i enabled it in in-cess and out-cess, but omemo option is still grayed out in conversations.
thelaughingman
@thelaughingman
hi everybody
I was wondering if anyone know a XMPP websocket library, written in C#