<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Why XMPP Part 2- Saving Your Resources</title>
	<atom:link href="http://pthree.org/2007/07/13/why-xmpp-part-2-saving-your-resources/feed/" rel="self" type="application/rss+xml" />
	<link>http://pthree.org/2007/07/13/why-xmpp-part-2-saving-your-resources/</link>
	<description>Linux.  GNU.  Freedom.</description>
	<lastBuildDate>Fri, 17 May 2013 20:46:35 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.6-beta2-24176</generator>
	<item>
		<title>By: Kent</title>
		<link>http://pthree.org/2007/07/13/why-xmpp-part-2-saving-your-resources/#comment-93743</link>
		<dc:creator>Kent</dc:creator>
		<pubDate>Sun, 23 Mar 2008 08:09:22 +0000</pubDate>
		<guid isPermaLink="false">http://www.pthree.org/2007/07/13/why-xmpp-part-2-saving-your-resources/#comment-93743</guid>
		<description><![CDATA[Just found this blog while looking for an explanation for something. 
As of today, I noticed gtalk is now coercing the hand-coded resource ID into a manipulated one with the random signuture, completely invalidating the whole notion of it representing a distinct endpoint, and now totally messing up my PSI conversations. ( psi treats every resource identifier as a distinct client/person so one can have 2 conversations with the same person via different resources simultaneously as it only uses the priority to identify which entity to make the primary connection to, not to relay every separate message )

Personally I think its a shocking shame google should so blatantly mess up the Jabber protocol like they have, its as bad as Internet Explorer back in the day adding their own custom weird random non-standard extensions which as we see now, have held the internet back from developing properly.  ( ie: their non-standard file transmission system completely incompatible with the standard )

I&#039;m going to have to start trying to push people from gTalk onto /real/ Jabber clients just to avoid the pain google is introducing.]]></description>
		<content:encoded><![CDATA[<p>Just found this blog while looking for an explanation for something.<br />
As of today, I noticed gtalk is now coercing the hand-coded resource ID into a manipulated one with the random signuture, completely invalidating the whole notion of it representing a distinct endpoint, and now totally messing up my PSI conversations. ( psi treats every resource identifier as a distinct client/person so one can have 2 conversations with the same person via different resources simultaneously as it only uses the priority to identify which entity to make the primary connection to, not to relay every separate message )</p>
<p>Personally I think its a shocking shame google should so blatantly mess up the Jabber protocol like they have, its as bad as Internet Explorer back in the day adding their own custom weird random non-standard extensions which as we see now, have held the internet back from developing properly.  ( ie: their non-standard file transmission system completely incompatible with the standard )</p>
<p>I&#8217;m going to have to start trying to push people from gTalk onto /real/ Jabber clients just to avoid the pain google is introducing.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: LINUX-Блоґ.org.ua &#187; Чому XMPP. Частина 2. Зберігаючи ваші ресурси</title>
		<link>http://pthree.org/2007/07/13/why-xmpp-part-2-saving-your-resources/#comment-67099</link>
		<dc:creator>LINUX-Блоґ.org.ua &#187; Чому XMPP. Частина 2. Зберігаючи ваші ресурси</dc:creator>
		<pubDate>Thu, 30 Aug 2007 14:23:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.pthree.org/2007/07/13/why-xmpp-part-2-saving-your-resources/#comment-67099</guid>
		<description><![CDATA[[...] &#8220;Why XMPP Part 2- Saving Your Resources&#8221;, Aaron [...]]]></description>
		<content:encoded><![CDATA[<p>[...] &#8220;Why XMPP Part 2- Saving Your Resources&#8221;, Aaron [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Hoàng Đức Hiếu</title>
		<link>http://pthree.org/2007/07/13/why-xmpp-part-2-saving-your-resources/#comment-64728</link>
		<dc:creator>Hoàng Đức Hiếu</dc:creator>
		<pubDate>Sat, 11 Aug 2007 07:48:51 +0000</pubDate>
		<guid isPermaLink="false">http://www.pthree.org/2007/07/13/why-xmpp-part-2-saving-your-resources/#comment-64728</guid>
		<description><![CDATA[@#5 by Askrates:

Fortunately Gajim has a really helpful toolstip for the Resource input box, if the user doesn&#039;t find it too lengthy to start reading.]]></description>
		<content:encoded><![CDATA[<p>@#5 by Askrates:</p>
<p>Fortunately Gajim has a really helpful toolstip for the Resource input box, if the user doesn&#8217;t find it too lengthy to start reading.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jelmer Vernooij</title>
		<link>http://pthree.org/2007/07/13/why-xmpp-part-2-saving-your-resources/#comment-61558</link>
		<dc:creator>Jelmer Vernooij</dc:creator>
		<pubDate>Mon, 16 Jul 2007 00:15:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.pthree.org/2007/07/13/why-xmpp-part-2-saving-your-resources/#comment-61558</guid>
		<description><![CDATA[@Bogomips
BitlBee doesn&#039;t have randomized resource strings at all. I agree with Aaron&#039;s comments on being able to set resources and BitlBee fully supports customizing resources or directing messages at specific resources.]]></description>
		<content:encoded><![CDATA[<p>@Bogomips<br />
BitlBee doesn&#8217;t have randomized resource strings at all. I agree with Aaron&#8217;s comments on being able to set resources and BitlBee fully supports customizing resources or directing messages at specific resources.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Aaron</title>
		<link>http://pthree.org/2007/07/13/why-xmpp-part-2-saving-your-resources/#comment-61501</link>
		<dc:creator>Aaron</dc:creator>
		<pubDate>Sun, 15 Jul 2007 14:37:53 +0000</pubDate>
		<guid isPermaLink="false">http://www.pthree.org/2007/07/13/why-xmpp-part-2-saving-your-resources/#comment-61501</guid>
		<description><![CDATA[@Evan-  Quite to the contrary.  I see no where within the client where I can change the priority to fit my needs.  The first connection gives a priority of 0, then each subsequent connection increases by 1.  This is all generated in the client itself.  The same is true for libgaim/libpurple clients.

Upon further investigation, you&#039;re right about the resource.  I can change this when I want, and only the Gmail.com provider appends the random hash, rather than the client.  This is good news.  At least that is something in the right direction.  I have updated the post to reflect the correct nature of these clients.]]></description>
		<content:encoded><![CDATA[<p>@Evan-  Quite to the contrary.  I see no where within the client where I can change the priority to fit my needs.  The first connection gives a priority of 0, then each subsequent connection increases by 1.  This is all generated in the client itself.  The same is true for libgaim/libpurple clients.</p>
<p>Upon further investigation, you&#8217;re right about the resource.  I can change this when I want, and only the Gmail.com provider appends the random hash, rather than the client.  This is good news.  At least that is something in the right direction.  I have updated the post to reflect the correct nature of these clients.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Evan Schoenberg</title>
		<link>http://pthree.org/2007/07/13/why-xmpp-part-2-saving-your-resources/#comment-61500</link>
		<dc:creator>Evan Schoenberg</dc:creator>
		<pubDate>Sun, 15 Jul 2007 14:29:05 +0000</pubDate>
		<guid isPermaLink="false">http://www.pthree.org/2007/07/13/why-xmpp-part-2-saving-your-resources/#comment-61500</guid>
		<description><![CDATA[Pidgin does allow you to specify the resource and to specify a priority associated with your status.

As aadam indicated, *every* Google Talk connection is going to have a server-generated or server-modified resource name; this has nothing to do with the client in use.  Pidgin and all other libpurple clients (including Adium) allow specifying of the resource you want to use.

It&#039;d be nice if you&#039;d edit your post to indicate that Pidgin, Adium, and other clients are just as capable in regards to resource and priority as the other XMPP clients you describe.  As it is, it is highly misleading.]]></description>
		<content:encoded><![CDATA[<p>Pidgin does allow you to specify the resource and to specify a priority associated with your status.</p>
<p>As aadam indicated, *every* Google Talk connection is going to have a server-generated or server-modified resource name; this has nothing to do with the client in use.  Pidgin and all other libpurple clients (including Adium) allow specifying of the resource you want to use.</p>
<p>It&#8217;d be nice if you&#8217;d edit your post to indicate that Pidgin, Adium, and other clients are just as capable in regards to resource and priority as the other XMPP clients you describe.  As it is, it is highly misleading.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bogomips</title>
		<link>http://pthree.org/2007/07/13/why-xmpp-part-2-saving-your-resources/#comment-61320</link>
		<dc:creator>Bogomips</dc:creator>
		<pubDate>Sat, 14 Jul 2007 11:40:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.pthree.org/2007/07/13/why-xmpp-part-2-saving-your-resources/#comment-61320</guid>
		<description><![CDATA[@Jelmer
But isn&#039;t one of the advantages of resources the fact that you can add someone to your list with someone@someserver.com/work and messages sent to that person would only be delivered to the client that had the &quot;work&quot; resource set?

Wouldn&#039;t server side (or even client side) random resource string generation take away that advantage?]]></description>
		<content:encoded><![CDATA[<p>@Jelmer<br />
But isn&#8217;t one of the advantages of resources the fact that you can add someone to your list with <a href="mailto:someone@someserver.com">someone@someserver.com</a>/work and messages sent to that person would only be delivered to the client that had the &#8220;work&#8221; resource set?</p>
<p>Wouldn&#8217;t server side (or even client side) random resource string generation take away that advantage?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Askrates</title>
		<link>http://pthree.org/2007/07/13/why-xmpp-part-2-saving-your-resources/#comment-61244</link>
		<dc:creator>Askrates</dc:creator>
		<pubDate>Fri, 13 Jul 2007 23:12:51 +0000</pubDate>
		<guid isPermaLink="false">http://www.pthree.org/2007/07/13/why-xmpp-part-2-saving-your-resources/#comment-61244</guid>
		<description><![CDATA[I really like the idea of being able to set resources manually. However, it just occurred to me after looking at your screenshot that most people would be absolutely clueless when presented with a box marked &quot;resource&quot;. It can be misinterpreted very easily. 
I suggest hiding options like this under an &quot;advanced&quot; tab, or at least doing something to make it more usable.]]></description>
		<content:encoded><![CDATA[<p>I really like the idea of being able to set resources manually. However, it just occurred to me after looking at your screenshot that most people would be absolutely clueless when presented with a box marked &#8220;resource&#8221;. It can be misinterpreted very easily.<br />
I suggest hiding options like this under an &#8220;advanced&#8221; tab, or at least doing something to make it more usable.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jelmer Vernooij</title>
		<link>http://pthree.org/2007/07/13/why-xmpp-part-2-saving-your-resources/#comment-61230</link>
		<dc:creator>Jelmer Vernooij</dc:creator>
		<pubDate>Fri, 13 Jul 2007 21:30:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.pthree.org/2007/07/13/why-xmpp-part-2-saving-your-resources/#comment-61230</guid>
		<description><![CDATA[Just to clarify: BitlBee has never used libgaim/libpurple. It was based on an older version of gaim, but except for a major part of the oscar implementation, it doesn&#039;t contain any of the gaim code anymore. The Jabber implementation was written from scratch.

Other than that, keep up the XMPP blog post. They&#039;re an interesting read!]]></description>
		<content:encoded><![CDATA[<p>Just to clarify: BitlBee has never used libgaim/libpurple. It was based on an older version of gaim, but except for a major part of the oscar implementation, it doesn&#8217;t contain any of the gaim code anymore. The Jabber implementation was written from scratch.</p>
<p>Other than that, keep up the XMPP blog post. They&#8217;re an interesting read!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Peter Saint-Andre</title>
		<link>http://pthree.org/2007/07/13/why-xmpp-part-2-saving-your-resources/#comment-61204</link>
		<dc:creator>Peter Saint-Andre</dc:creator>
		<pubDate>Fri, 13 Jul 2007 17:39:16 +0000</pubDate>
		<guid isPermaLink="false">http://www.pthree.org/2007/07/13/why-xmpp-part-2-saving-your-resources/#comment-61204</guid>
		<description><![CDATA[@Aadaam: It is NOT TRUE that distinguishing resources by resource strings will be deprecated. However, we are going to recommend (but not require) that servers generate resource strings on behalf of clients -- there are some security concerns related to client-generated resource identifiers.]]></description>
		<content:encoded><![CDATA[<p>@Aadaam: It is NOT TRUE that distinguishing resources by resource strings will be deprecated. However, we are going to recommend (but not require) that servers generate resource strings on behalf of clients &#8212; there are some security concerns related to client-generated resource identifiers.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Aadaam</title>
		<link>http://pthree.org/2007/07/13/why-xmpp-part-2-saving-your-resources/#comment-61193</link>
		<dc:creator>Aadaam</dc:creator>
		<pubDate>Fri, 13 Jul 2007 16:36:57 +0000</pubDate>
		<guid isPermaLink="false">http://www.pthree.org/2007/07/13/why-xmpp-part-2-saving-your-resources/#comment-61193</guid>
		<description><![CDATA[Distinguishing resources by resource strings will be deprecated in the upcoming version of XMPP.

As for the resource hash appended to the end, it&#039;s probbaly not pidgin&#039;s fault, but it&#039;s a GTalk &quot;feature&quot;: in core XMPP standard (rfc 3920-21), it is written that a server CAN force a resource ID, and so does google.]]></description>
		<content:encoded><![CDATA[<p>Distinguishing resources by resource strings will be deprecated in the upcoming version of XMPP.</p>
<p>As for the resource hash appended to the end, it&#8217;s probbaly not pidgin&#8217;s fault, but it&#8217;s a GTalk &#8220;feature&#8221;: in core XMPP standard (rfc 3920-21), it is written that a server CAN force a resource ID, and so does google.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
