Re: Future of jabberd

2016-05-31 Thread Tomasz Sterna
W dniu 30.05.2016, pon o godzinie 20∶05 +0200, użytkownik Tomasz Sterna napisał: > I am still not fond of the synchronous nature of storage interface, > but changing this would require rewriting it from scratch. > Also having an asynchronous interface for immediate in nature > backends like file

Re: Future of jabberd

2016-05-31 Thread Tomasz Sterna
W dniu 31.05.2016, wto o godzinie 16∶31 +, użytkownik Shawn Debnath napisał: > Re 1. Merging separate daemons to one. > I am not sure if merging them into one process is the best idea. It > sure is convenient, but isolation is a nice thing to have. Specially, > when you have unauthorized users

Re: Future of jabberd

2016-05-31 Thread Shawn Debnath
I agree with Tomasz that there are changes that are definitely needed given how much technology has changed since jabberd2 was first released. Re 1. Merging separate daemons to one. I am not sure if merging them into one process is the best idea. It sure is convenient, but isolation is a nice

Re: Future of jabberd

2016-05-31 Thread Ed - 0x1b, Inc.
On Mon, May 30, 2016 at 9:32 PM, Tomasz Sterna wrote: > 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

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 lists
To: jabberd2@lists.xiaoka.com Reply To: jabberd2@lists.xiaoka.com Subject: Re: Future of jabberd 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 th

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
@lists.xiaoka.com Reply To: jabberd2@lists.xiaoka.com Subject: Re: Future of jabberd 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 fe

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 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 lists
To: jabberd2@lists.xiaoka.com‎ Reply To: jabberd2@lists.xiaoka.com Subject: Re: Future of jabberd 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

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 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
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 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

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

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