<div dir="ltr">On Fri, Oct 17, 2008 at 1:59 PM, Mark Doliner <span dir="ltr"><<a href="mailto:mark@kingant.net">mark@kingant.net</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Thu, Oct 16, 2008 at 9:46 PM, Sebastiaan Deckers <<a href="mailto:cbas@pandion.be">cbas@pandion.be</a>> wrote:<br>
> There is never any case of "SRV lookup on the SRV lookups".<br>
> Rather the user (eg. <a href="mailto:j.doe@gmail.com">j.doe@gmail.com</a>) would specify in the client a hard<br>
> coded hostname (eg. <a href="http://talk.google.com" target="_blank">talk.google.com</a>) for their XMPP server. The client then<br>
> uses SRV resolution on that hardcoded address.<br>
> This allows the server to distribute client connections across a cluster<br>
> using SRV weights, even if it can't support SRV on its main DNS address.<br>
> Without SRV resolution such hard coded address could as not easily be load<br>
> shared across nodes.<br>
> Of course if the SRV lookup fails on the hard coded address then client will<br>
> continue to a regular name lookup.<br>
> Am I overlooking some downside to trying SRV lookup on the hard coded<br>
> address?<br>
<br>
</div>I don't see any major downside, but I also don't think it's a good<br>
idea.  I think this is a very unnecessary feature, and I think it<br>
needlessly complicates the code.  I think very few people will benefit<br>
from this, if any.  Yes it is just one little feature, but you've got<br>
to draw the line somewhere.  libpurple is pretty large, and I think<br>
this is something we should consciously chose not to include.<br>
</blockquote><div><br>I don't know about the libpurple code base but once SRV lookups have been implemented (which XMPP Core requires) then couldn't you easily re-use that code? I don't see how it adds any complexity. In fact there is less complexity because there's only a single way to look up XMPP hostnames instead of two different code paths.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Your possible use case is that there might exist a jabber domain with<br>
so many users that they need to load balance their incoming<br>
connections, and that whoever is running this huge jabber network is<br>
unable to create DNS SRV record for their domain, but is somehow able<br>
to create DNS SRV records for the domain that people user as the<br>
connect server?  That sounds very contrived to me.<font color="#888888"><br>
</font></blockquote></div><br>Not as alien as you think it might be. In fact I'm involved in a project just like.<br>Imagine a network of people who sign up with their existing email address. These addresses could be used by the network as XMPP IDs. So a user could log in with Pandion or Pidgin or any other XMPP client using an ID "<a href="mailto:billg@microsoft.com">billg@microsoft.com</a>" and set the connect server as "<a href="http://some-huge-xmpp-cluster.org">some-huge-xmpp-cluster.org</a>"<br>
That cluster could support huge numbers of domains and users which don't yet have SRV records.<br><br>Seems like a valid use case to me, and SRV lookups of the connect server makes it that much easier to implement.<br>
<br>-Sebastiaan<br></div>