Fwd: jabberd2 in cluster? ideas, proof of concept and questions...

2012-10-13 Thread James Wilson

Just thought of this: if you use an 'auto-config' type setting, perhaps we 
could take a 'Bonjour' like route in that each server broadcasts within its 
local IP range / subnet for other XMPP servers and makes a live, real time list 
of available instances.

Regards,
  James

This message was sent from my iPhone

 On 13/10/2012, at 4:53, Tomasz Sterna to...@xiaoka.com wrote:
 
 Dnia 2012-10-12, pią o godzinie 17:18 +0200, Alexandre Jousset pisze:
 Maybe it would be a good thing to say this (only 1 SM per domain to use 
 less memory) in the install / config guide after the changes.
 
 I've now reread it and got it.
 Yes, it is worth mentioning in the documentation.
 
 
   We do. In the simplest way to do it, routers don't forward other routers' 
 binding requests. Of course it is possible to implement it to allow 
 multi-hops, but I'm afraid this could lead to problems (and inefficiency) 
 for no real gain (except simplistic configuration). Of course it would be 
 easier to only list just one router of the mesh when adding a router, but I 
 would prefer sacrificing this easiness in favor of efficiency. After all, 
 the administrator has all knowledge about its server architecture. So when 
 adding a router, the config file should list *all* other already running 
 routers in the mesh.
 
 What if you do not manage all the routers in the mesh?
 And you were given a password to access only one or two routers of the
 mesh?
 
 In my proposal nothing stops you from making each router know all the
 others to make it more efficient, but it shouldn't be _required_.
 
 
   Also, in the pseudo-code I've written (and started to implement) I had to 
 make a distinction between local components and remote routers, just for 
 efficiency, to allow the use of a local component preferably before trying 
 a remote one. So the local components have greater priorities than remote 
 ones, and both are chosen with weighted random in their category. What do 
 you think about this?
 
 Explicit is better than implicit.
 If you want local components to have higher priority - just say so in
 the configuration file. But default should be that remote binds are as
 equal as local ones.
 
 
   Finally, I've added a routers.xml file (with a final 's', naming can be 
 changed of course) to allow reloading it dynamically to change its 
 connections settings if needed. What do you think about this? Do you think 
 it could be necessary?
 
 Seams reasonable and simple.
 remote-routers.xml maybe?
 
 
 -- 
 Tomasz Sterna
 Instant Messaging Consultant : Open Source Developer
 http://tomasz.sterna.tv/  http://www.xiaoka.com/portfolio
 
 
 




Re: Working around client bugs in server software

2012-10-13 Thread Ed - 0x1b, Inc.
On Fri, Oct 12, 2012 at 6:27 AM, Tomasz Sterna to...@xiaoka.com wrote:
 Dnia 2012-10-12, pią o godzinie 14:50 +0200, Alexandre Jousset pisze:
 According to this link the bug is marked as resolved, fixed.
 Do you think clients haven't upgraded and still have the bug?

 asmack was patched in Beem only. Maven repos still have Smack 3.2.1.
 So unfortunately - most Java code using Smack still has this bug.

 And more importantly - this is just an example serving me to ask a
 broader question.


 --
 Tomasz Sterna
 Instant Messaging Consultant : Open Source Developer
 http://tomasz.sterna.tv/  http://www.xiaoka.com/portfolio



Are you suggesting the server have an auditbot to evaluate the
quality of clients and maintain patches that may be requested from the
server's admin?
If the world is righteous, no bother no fuss - if the world has
fallen, there is a way up and the local admin gets notice. If the
local admin knows his clients aren't righteous, deployment with
patches should be an option. A good ontology for this is EARL
http://www.w3.org/WAI/intro/earl

This would make each jabberd2 server a QA tool..  :)   there be statistics thar