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 ba
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
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 th
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 distributed SM only?
>
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
2016 4:30 PM
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 da
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.
Unfortunatel
berd2@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 f
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, which
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 consid
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 a
: 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 it
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.
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, li...@lazyg
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
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 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 1
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 on
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 improvements,
19 matches
Mail list logo