There are some things we already talked about on Gitter channel ,
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
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
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 -
6) important is easy integration with ELK stack
7) i hope its better than unixODBC
Dne 30.5.2016 v
I tried multiple times sending email to
jabberd2+unsubscr...@lists.xiaoka.com and nothing.
Can you please manually remove me from the list?
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.
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
On 30.05.2016 16:43,
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
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
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.
W dniu 30.05.2016, pon o godzinie 12∶50 -0700, użytkownik
> 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.
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
This is interesting reading:
W dniu 30.05.2016, pon o godzinie 10∶31 +0200, użytkownik Tomasz Sterna
> 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
W dniu 30.05.2016, pon o godzinie 10∶00 -0700, użytkownik
> 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
W dniu 30.05.2016, pon o godzinie 17∶38 +0300, użytkownik brahmann
> 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
W dniu 30.05.2016, pon o godzinie 15∶40 +0200, użytkownik Matěj Cepl
> by heart, don't you? When doing large changes in the
> codebase, it would be probably prudent to take those
> objections into
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.
From: Tomasz Sterna
Sent: Monday, May 30, 2016 11:40 AM
Mail list logo