Future of jabberd

2016-05-30 Thread Tomasz Sterna
There are some things we already talked about on Gitter channel [1], but I would like to raise them on the ML for peer review. As you can see from late activity, jabberd2 project is far from dead. With the inclusion of new features like WebSocket support, C99 code compatibility, IPv6

Re: Future of jabberd

2016-05-30 Thread brahmann
Hi, about all - good direction i think! 1. Event-driven single - good choice. 2. There are alot of other good libraries like libev too, but libuv - good, used it in my work pretty stable with 300-1000 events per loop. But last time we using libev coz FreeBSD releated more. 5. About js, logic

Re: Future of jabberd

2016-05-30 Thread Marek Červenka
i see Phoenix rise from the ashes ... ;) +1 for all 2) libuv is used by node.js - good choice 4) i'm coming from telco side - https://wiki.asterisk.org/wiki/display/AST/ARI+Push+Configuration 6) important is easy integration with ELK stack 7) i hope its better than unixODBC Dne 30.5.2016 v

unsubscribe

2016-05-30 Thread Wagner Sartori Junior
I tried multiple times sending email to jabberd2+unsubscr...@lists.xiaoka.com and nothing. Can you please manually remove me from the list? BR, Wagner

Re: Future of jabberd

2016-05-30 Thread lists
Regarding item 4, seriously, does everything ‎these days have to have a web interface? It just increases the attack surface. Adding a web interface means one more thing to protect against hackers, which means writing rules for the WAF or adding something else for fail2ban or sshguard to watch. 

Re: Future of jabberd

2016-05-30 Thread brahmann
Agree (web). I wrote some years ago simple web interface for jabberd2, need to review it and rewrite for new one later. Its will be good for those who want it but not in jabberd2 code inside. Using it with mysql and postgresql - works perfectly wbr, brahmann On 30.05.2016 16:43,

Re: Future of jabberd

2016-05-30 Thread Matěj Cepl
On 2016-05-30, 08:31 GMT, Tomasz Sterna wrote: > But it is far from modern too... > There are some changes I would like to introduce in the near future and > I would like to hear your thoughts about: I completely agree with these comments: 1. It would be probably wise to maintain stable jabberd2

Re: Future of jabberd

2016-05-30 Thread lists
That is one of the beauties of programs written around standard tools like ‎sql. You can hook into the database and add features, or not. ;-) In defense of web interfaces, you can hand off that administration task to someone else without granting login access to the server. Or depending on your

Re: Future of jabberd

2016-05-30 Thread Greg Troxel
I'd also like to see multi-user conferencing integrated. I did a little maintenance on the muc plugin a few years ago, but the code is still too scary.

Re: Future of jabberd

2016-05-30 Thread Tomasz Sterna
W dniu 30.05.2016, pon o godzinie 12∶50 -0700, użytkownik li...@lazygranch.com napisał: > Do you really have to cache something in jabberd when the data can be > pulled from the sql database? Sure the data has changed. But if you > pull a fresh record each time, I don't see the issue.

Re: Future of jabberd

2016-05-30 Thread lists
If you can create and maintain the database through standard programs (sqlite being my favorite), I don't mind the caching. But in a system that uses TLS, is a database lookup that significant of a time sink in the whole transaction flow.  This is interesting reading:

Re: Future of jabberd

2016-05-30 Thread Tomasz Sterna
W dniu 30.05.2016, pon o godzinie 10∶31 +0200, użytkownik Tomasz Sterna napisał: > 7. DBI interface to RDBM. Just one more question. Do you (ML) have a use case for having SM storage in SQL? Is it just for distributed SM only? Maybe it is not worth the effort and we should just drop it and embed

Re: Future of jabberd

2016-05-30 Thread Tomasz Sterna
W dniu 30.05.2016, pon o godzinie 10∶00 -0700, użytkownik li...@lazygranch.com napisał: > That is one of the beauties of programs written around standard tools > like ‎sql. You can hook into the database and add features, or not. The issue with this approach is that SM component caches user data

Re: Future of jabberd

2016-05-30 Thread Tomasz Sterna
W dniu 30.05.2016, pon o godzinie 17∶38 +0300, użytkownik brahmann napisał: > Agree (web). [...] Its will be good for those who want it  > but not in jabberd2 code inside. I like how Cherokee web server does this: It has a separate (written in Python) application for Web-based configuration,

Re: Future of jabberd

2016-05-30 Thread Tomasz Sterna
W dniu 30.05.2016, pon o godzinie 15∶40 +0200, użytkownik Matěj Cepl napisał: >    https://metajack.wordpress.com/2008/08/26/choosing-an-xmpp-server/ >   >    by heart, don't you? When doing large changes in the  >    codebase, it would be probably prudent to take those  >    objections into

Re: Future of jabberd

2016-05-30 Thread lists
Do you really have to cache something in jabberd when the data can be pulled from the sql database? Sure the data has changed. But if you pull a fresh record each time, I don't see the issue.   Original Message   From: Tomasz Sterna Sent: Monday, May 30, 2016 11:40 AM To: