On 6/5/08, Jean de Largentaye <[EMAIL PROTECTED]> wrote:
> Well, I think it is rather ironic, because the original design
> specifically went for multiple executables that could be able to
> distribute the load on different networked servers.
This point was addressed in other parts of the thread
Tomasz Sterna wrote:
Dnia 2008-06-05, czw o godzinie 11:18 -0400, Christopher Zorn pisze:
> And wouldn't keep one from running each component in
separate
> process - just run only one thread+component in each
instance.
I believe this would be a mistake. The origi
Dnia 2008-06-05, czw o godzinie 11:18 -0400, Christopher Zorn pisze:
> > And wouldn't keep one from running each component in
> separate
> > process - just run only one thread+component in each
> instance.
>
> I believe this would be a mistake. The original design i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Since mine is a small deployment, I don't have strong feelings
either way, although I'd find a single binary easier to deal
with since I don't need the across-multiple-machines scalability
of separate binaries.
But I'd like to suggest a solution: c
On Thu, 05 Jun 2008 14:33:49 +0200
Tomasz Sterna <[EMAIL PROTECTED]> wrote:
> We were talking with Ono today about merging all jabberd 2 sub
> applications (router, c2s, s2s, sm) into one binary, with multiple
> threads running each components.
> That would mainly reduce maintenance and deployment
Hello Tomasz,
Tomasz Sterna schrieb:
> We were talking with Ono today about merging all jabberd 2 sub
> applications (router, c2s, s2s, sm) into one binary, with multiple
> threads running each components.
> That would mainly reduce maintenance and deployment effort. You would
> run one process in
On Thu, Jun 5, 2008 at 8:33 AM, Tomasz Sterna <[EMAIL PROTECTED]> wrote:
> We were talking with Ono today about merging all jabberd 2 sub
> applications (router, c2s, s2s, sm) into one binary, with multiple
> threads running each components.
> That would mainly reduce maintenance and deployment ef
Dnia 2008-06-05, czw o godzinie 16:18 +0200, Jean de Largentaye pisze:
> Well, I think it is rather ironic, because the original design
> specifically went for multiple executables that could be able to
> distribute the load on different networked servers. Wasn't it one of
> the reasons of the rede
Well, I think it is rather ironic, because the original design
specifically went for multiple executables that could be able to
distribute the load on different networked servers. Wasn't it one of
the reasons of the redesign from jabberd14?
I realize the question is whether this use-case is effici
Tomasz Sterna wrote:
We were talking with Ono today about merging all jabberd 2 sub
applications (router, c2s, s2s, sm) into one binary, with multiple
threads running each components.
That would mainly reduce maintenance and deployment effort. You would
run one process instead of several ones.
An
We were talking with Ono today about merging all jabberd 2 sub
applications (router, c2s, s2s, sm) into one binary, with multiple
threads running each components.
That would mainly reduce maintenance and deployment effort. You would
run one process instead of several ones.
And wouldn't keep one fro
11 matches
Mail list logo
