Working around client bugs in server software
There is a SMACK-324 [1] bug affecting a lot of Java client applications (including most Android clients). It would be trivial to work around it in jabberd2 codebase, but it just doesn't feel right. From practical point of view: There is a trivial fix we can have on - let's just do it and make our users happy. And current jabberd2 development philosophy is a stable server that just works. But there is a danger of: - never fixing the original issue if we stop exposing it - jabberd becoming an unmaintainable bag of patches for problems not in jabberd I would like to hear your opinions how should we approach such issues. [1] http://issues.igniterealtime.org/browse/SMACK-324 -- 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
Le 12/10/2012 10:42, Tomasz Sterna a écrit : There is a SMACK-324 [1] bug affecting a lot of Java client applications (including most Android clients). It would be trivial to work around it in jabberd2 codebase, but it just doesn't feel right. From practical point of view: There is a trivial fix we can have on - let's just do it and make our users happy. And current jabberd2 development philosophy is a stable server that just works. But there is a danger of: - never fixing the original issue if we stop exposing it - jabberd becoming an unmaintainable bag of patches for problems not in jabberd I would like to hear your opinions how should we approach such issues. [1] http://issues.igniterealtime.org/browse/SMACK-324 According to this link the bug is marked as resolved, fixed. Do you think clients haven't upgraded and still have the bug? -- -- \^/-- ---/ O \----- -- | |/ \| Alexandre (Midnite) Jousset | -- ---|___|-----
Re: Working around client bugs in server software
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
Re: jabberd2 in cluster? ideas, proof of concept and questions...
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
