From jonathan.dickinson at k2.com  Wed Apr  1 06:52:14 2009
From: jonathan.dickinson at k2.com (Jonathan Dickinson)
Date: Wed, 1 Apr 2009 13:52:14 +0200
Subject: [jdev] APML and PubSub
Message-ID: <A790BE8D83ECC3469047C2E344EABE61027C5A3F725B@zamail01.k2workflow.com>

Hi All,

I thought someone might want to do something interesting with this technology.

""APML allows users to share their own personal Attention Profile in much the same way that OPML allows the exchange of reading lists between News Readers. The idea is to compress all forms of Attention Data into a portable file format containing a description of ranked user interests.""

Given an APML binding for each PubSub node (e.g. "user interface") a PubSub service could provide a user with a list of suggested nodes based on an APML document that they provide (via IQ or something): or automatically send them publications in any node based on each publications' tags.

Furthermore, if the PubSub spec got a little 'smarter' the author could set the 'affinity' for each post's tag: allowing them to indicate how well the post relates to the particular tag. This could be used to filter publications based on the "value" attribute in the APML. Thus:

Known APMLs:
Fred:
 Food 0.6
 User Interface 0.9
Jane
 Food 0.8
 User Interface 0.3

Subscriber Creates Publication:
 Food (3/5 = 0.6 - Invert = 0.4)
 Sends to  Fred and Jane
Another one:
 User Interface (2/5 = 0.4 - Invert = 0.6)
 Sends to  Fred

Just some hashing out of some ideas; I don't have the time to really go at it. Just wanted to throw it out there and see what you all think: maybe someone will hop on it and write a XEP.

<http://www.apml.org/>

-- Jonathan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/jdev/attachments/20090401/b6ae5a4e/attachment.htm 

From mwild1 at gmail.com  Wed Apr  1 11:58:55 2009
From: mwild1 at gmail.com (Matthew Wild)
Date: Wed, 1 Apr 2009 17:58:55 +0100
Subject: [jdev] [ANN] Prosody 0.4.0 Released
Message-ID: <4db9cacb0904010958je6769fbm9b7bfdd2e6090e9@mail.gmail.com>

We are pleased to announce the release of Prosody 0.4.0.

It's no joke. We have spent most effort this release improving
Prosody internals, ensuring we have a solid base on which to build
future features. Numerous bugs have been fixed and we recommend
that all users of 0.3.0 upgrade.

That said, we do have a few new things in this release, namely
roster versioning (allowing clients to cache the roster, instead
of downloading it each time they connect) and support for external
components, allowing the use of gateways/transports and other services.

Prosody is a lightweight Jabber/XMPP server written in Lua. It aims
to be flexible, easy to extend, and simple to use for both users
and developers alike.

The following is a summary of changes since the previous version:

   * Numerous stability fixes (highly recommended 0.3 users upgrade)
   * XEP-0114 support for external components (experimental)
   * mod_xmlrpc: Allow RPC calls over HTTP/XMPP to command a server
   * Roster versioning, to allow faster logins (experimental)
   * Fix BOSH race condition with multiple idle sessions
   * Handle missing <priority> in initial client presence
   * Fix for correct pass-through of stanzas with prefixed attributes
   * Fix routing of some stanzas directed to bare JIDs
   * Config improvements, better error reporting, Include command
   * SASL ANONYMOUS support for anonymous login when enabled
   * mod_version now reports OS type (configurable)
   * MUC: Support PMs, vCards, and misc. reliability fixes
   * Module API: Add stanza.clone, timers, and more
   * Various logging improvements

We would appreciate feedback from those testing roster versioning -
we are aware of no clients that support it currently, but hopefully
that can soon change.

Testing external component support would greatly help too, there
are many different components, and we have only tried a couple.

All of the known issues listed in the previous release have been fixed.

Download: http://prosody.im/download/

Happy Jabbering,
  The Prosody Team

From simon at buddycloud.com  Wed Apr  1 14:10:21 2009
From: simon at buddycloud.com (Simon Tennant)
Date: Wed, 01 Apr 2009 21:10:21 +0200
Subject: [jdev] update on XMPP location (wherein beer is offered)
In-Reply-To: <28B8BE8DCC88448192FEF978639142CC@movsoftware.com>
References: <28B8BE8DCC88448192FEF978639142CC@movsoftware.com>
Message-ID: <49D3BC1D.90504@buddycloud.com>

Stephen Pendleton wrote:
> I like this a lot. How does the "nearby" query work? Does it returned
> bookmarked places that are owned by the submitting jid, or any bookmarked
> place nearby? What is "cellpatternquality" mean?
A place can have one of two modes.

    * Public places are those that can be shared with other people. Eg
      my placemark for Starbucks would be useful to others.
    * Private places are those that will not be shared with others. For
      example my placemark called "Home sweet home" is probably not
      useful to others on the network (and/or I want it to be private to
      just me and only shared with my friends).

butler.buddycloud.com will only show public in a nearby query. These
will be public places from all users. Additionally you can subscribe to
a place which then places it on your own list of places that you are
placed at in the future.

CellPatternQuality reflects the certainty of the place.  How "distinct"
it is. For example when you are driving the location butler will be
seeing lots of new wifi and cell towers. Saving a placemark at that
point will save it but it will be a "blurry" pattern in the database. 
Better would be to wait a moment, submit a couple more location queries,
watch for the cellpatternquality to increase to 100% and then send a
placemark save stanza.  Then the butler will be far more likely to
accurately place you back at that point in the future.

> Also, how does the component push my location to my PEP node if I am on
> another server? Would this be allowed by XMPP servers? I would be
> interested
> in seeing these stanzas though to test it out.
Indeed for non-buddycloud.com domains PEP would not work. There are two
solutions for this that we are looking at. Either:

    * having the remote non buddycloud node publish their own pep node
      after getting a reply to their location query stanza or
    * granting publisher rights to butler.buddycloud.com on your own
      pubsub geoloc node and passing the address to this node as part of
      the location query. The query results would then be published on
      your behalf in XEP-0080 (user location) format as well as being
      returned to the client.

> There is another application we are working on that involves XEP-0255. It
> currently supports what you are calling "beacon logs" stanzas to
> return back
> postal addresses. The system uses a combination of wifi access
> points/mobile
> towers to pinpoint your position and return back a lat/lon. It is very
> accurate in a populated area.
The butler does a best effort on the lookup of lat/long too and
publishes it as part of the XEP-0080 stack. I don't think we fill out
the post code for general locations (we do for known places) but this
could presumably be added with access to the right lat/long -> postcode
mapping tables.  It's not something that we have spent too much time on.
Our main efforts in butler development have focused on making location
something social by describing it as known places like home or work or
"on the road in munich" (travelling) or  "near  Jo's house" for example.

S.

-- 
Simon Tennant
Buddycloud
uk: +44 20 7043 6756               de: +49 89 420 955 854  
uk: +44 78 5335 6047               de: +49 17 8545 0880
email and xmpp: simon at buddycloud.com
http://buddycloud.com


From stpeter at stpeter.im  Thu Apr  2 20:23:31 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 02 Apr 2009 19:23:31 -0600
Subject: [jdev] jabber.org account registration policy
Message-ID: <49D56513.5080201@stpeter.im>

http://www.jabber.org/index.php/2009/04/account-registration-policy/ says:

The Jabber.org IM service has instituted a new account registration
policy. Until further notice, IM accounts can be registered only via the
web at register.jabber.org, which means that our longtime practice of
allowing in-band registration using an IM client has been disabled.

You will notice that register.jabber.org requires you to complete a
?CAPTCHA? test in order to create an account. This is a security measure
to help prevent bulk account creation by automated processes. We might
deploy further account security measures in the future, and will
announce any such changes at the jabber.org website.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/jdev/attachments/20090402/4f15d829/attachment.bin 

From stpeter at stpeter.im  Thu Apr  2 23:17:08 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 02 Apr 2009 22:17:08 -0600
Subject: [jdev] client developers take note: list of IM services
Message-ID: <49D58DC4.3080601@stpeter.im>

Because of yet another jabber.org website change, we've moved the XML
file that provides an automated listing of the public XMPP servers.

Originally it was here: http://jabber.org/servers.xml

Then it was here: http://jabber.org/basicservers.xml

Now it is here: http://xmpp.org/services/services.xml

HTTP redirects are supposed to be in place, but there is no guarantee
that they are working. Please verify and let me know.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/jdev/attachments/20090402/e248cb6a/attachment.bin 

From elmex at x-paste.de  Fri Apr  3 03:44:01 2009
From: elmex at x-paste.de (Robin Redeker)
Date: Fri, 3 Apr 2009 10:44:01 +0200
Subject: [jdev] client developers take note: list of IM services
In-Reply-To: <49D58DC4.3080601@stpeter.im>
References: <49D58DC4.3080601@stpeter.im>
Message-ID: <20090403084400.GB10294@kiste.laendle>

On Thu, Apr 02, 2009 at 10:17:08PM -0600, Peter Saint-Andre wrote:
> Because of yet another jabber.org website change, we've moved the XML
> file that provides an automated listing of the public XMPP servers.
> 
> Originally it was here: http://jabber.org/servers.xml
> 
> Then it was here: http://jabber.org/basicservers.xml
> 
> Now it is here: http://xmpp.org/services/services.xml
> 
> HTTP redirects are supposed to be in place, but there is no guarantee
> that they are working. Please verify and let me know.

http://www.jabber.org/servers.xml redirects to http://xmpp.org/software/servers.shtml

which is a list of server software...

And http://jabber.org/basicservers.xml is a redirect to http://www.jabber.org/basicservers.xml
which is a redirect to http://www.xmpp.org/services/services.xml

And http://xmpp.org/services/services.xml is 404 Not Found.

Greetings,
   Robin

-- 
Robin Redeker                         | Deliantra, the free code+content MORPG
elmex at ta-sa.org / r.redeker at gmail.com | http://www.deliantra.net
http://www.ta-sa.org/                 |

From stpeter at stpeter.im  Fri Apr  3 08:11:25 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 03 Apr 2009 07:11:25 -0600
Subject: [jdev] client developers take note: list of IM services
In-Reply-To: <20090403084400.GB10294@kiste.laendle>
References: <49D58DC4.3080601@stpeter.im>
	<20090403084400.GB10294@kiste.laendle>
Message-ID: <49D60AFD.2050707@stpeter.im>

On 4/3/09 2:44 AM, Robin Redeker wrote:
> On Thu, Apr 02, 2009 at 10:17:08PM -0600, Peter Saint-Andre wrote:
>> Because of yet another jabber.org website change, we've moved the XML
>> file that provides an automated listing of the public XMPP servers.
>>
>> Originally it was here: http://jabber.org/servers.xml
>>
>> Then it was here: http://jabber.org/basicservers.xml
>>
>> Now it is here: http://xmpp.org/services/services.xml
>>
>> HTTP redirects are supposed to be in place, but there is no guarantee
>> that they are working. Please verify and let me know.
> 
> http://www.jabber.org/servers.xml redirects to http://xmpp.org/software/servers.shtml

Fixed.

> which is a list of server software...
> 
> And http://jabber.org/basicservers.xml is a redirect to http://www.jabber.org/basicservers.xml
> which is a redirect to http://www.xmpp.org/services/services.xml

Fixed.

> And http://xmpp.org/services/services.xml is 404 Not Found.

Fixed.

Thanks for testing!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/jdev/attachments/20090403/c2a97e83/attachment-0001.bin 

From sander at sanderdevrieze.net  Fri Apr  3 11:34:35 2009
From: sander at sanderdevrieze.net (Sander Devrieze)
Date: Fri, 3 Apr 2009 18:34:35 +0200
Subject: [jdev] jabber.org account registration policy
In-Reply-To: <49D56513.5080201@stpeter.im>
References: <49D56513.5080201@stpeter.im>
Message-ID: <7b06a4100904030934i68b16cc2h8bedf5e9127c0ebb@mail.gmail.com>

2009/4/3 Peter Saint-Andre <stpeter at stpeter.im>:
> http://www.jabber.org/index.php/2009/04/account-registration-policy/ says:
>
> The Jabber.org IM service has instituted a new account registration
> policy. Until further notice, IM accounts can be registered only via the
> web at register.jabber.org, which means that our longtime practice of
> allowing in-band registration using an IM client has been disabled.

Would it be possible to remove jabber.org from
http://xmpp.org/services/services.xml ? I think that list makes no
sense when it contains services which are not in-band registration
capable...


-- 
Mvg, Sander Devrieze.

From lambda512 at gmail.com  Sat Apr  4 07:30:57 2009
From: lambda512 at gmail.com (naw)
Date: Sat, 4 Apr 2009 14:30:57 +0200
Subject: [jdev] jabber.org account registration policy
In-Reply-To: <7b06a4100904030934i68b16cc2h8bedf5e9127c0ebb@mail.gmail.com>
References: <49D56513.5080201@stpeter.im>
	<7b06a4100904030934i68b16cc2h8bedf5e9127c0ebb@mail.gmail.com>
Message-ID: <200904041430.58372.lambda512@gmail.com>

El Viernes 03 Abril 2009, Sander Devrieze escribi?:
> 2009/4/3 Peter Saint-Andre <stpeter at stpeter.im>:
> > http://www.jabber.org/index.php/2009/04/account-registration-policy/
> > says:
> >
> > The Jabber.org IM service has instituted a new account registration
> > policy. Until further notice, IM accounts can be registered only via the
> > web at register.jabber.org, which means that our longtime practice of
> > allowing in-band registration using an IM client has been disabled.
>
> Would it be possible to remove jabber.org from
> http://xmpp.org/services/services.xml ? I think that list makes no
> sense when it contains services which are not in-band registration
> capable...

I think that it mades sense to have a list of federated servers. It can be 
useful for other things. But maybe there should be some aditional information 
about the servers (if they support in-band registration), or maybe several 
lists (e.g. one for all servers, another one for servers wich support 
in-band...)

Also, if in-band registration is going to be less used by servers until the 
implementation of XEP-0158 (captchas) in servers and clients, it could be 
also useful to provide the registration address as a child element in the 
list.

-- 

Jabber-ID: lambda512 at jabberes.org lambda512 at gmail.com

From stpeter at stpeter.im  Sat Apr  4 14:13:31 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Sat, 04 Apr 2009 13:13:31 -0600
Subject: [jdev] jabber.org account registration policy
In-Reply-To: <200904041430.58372.lambda512@gmail.com>
References: <49D56513.5080201@stpeter.im>	<7b06a4100904030934i68b16cc2h8bedf5e9127c0ebb@mail.gmail.com>
	<200904041430.58372.lambda512@gmail.com>
Message-ID: <49D7B15B.8070902@stpeter.im>

On 4/4/09 6:30 AM, naw wrote:
> El Viernes 03 Abril 2009, Sander Devrieze escribi?:
>> 2009/4/3 Peter Saint-Andre <stpeter at stpeter.im>:
>>> http://www.jabber.org/index.php/2009/04/account-registration-policy/
>>> says:
>>>
>>> The Jabber.org IM service has instituted a new account registration
>>> policy. Until further notice, IM accounts can be registered only via the
>>> web at register.jabber.org, which means that our longtime practice of
>>> allowing in-band registration using an IM client has been disabled.
>> Would it be possible to remove jabber.org from
>> http://xmpp.org/services/services.xml ? I think that list makes no
>> sense when it contains services which are not in-band registration
>> capable...

Done.

> I think that it mades sense to have a list of federated servers. It can be 
> useful for other things. But maybe there should be some aditional information 
> about the servers (if they support in-band registration), or maybe several 
> lists (e.g. one for all servers, another one for servers wich support 
> in-band...)

I think it's best if services.xml includes only services that support
in-band registration (IBR), because this file is used by clients to
present a list of services for account registration.

> Also, if in-band registration is going to be less used by servers until the 
> implementation of XEP-0158 (captchas) in servers and clients, it could be 
> also useful to provide the registration address as a child element in the 
> list.

Given the recent (and growing) problems with automated processes
registering large numbers of accounts on public XMPP services, I think
that IBR will soon become unworkable without XEP-0158 support in clients
and servers. Until that happens, we will diable IBR at jabber.org (and I
expect many other public XMPP services to do the same). IBR was a great
idea back in 1999 when no one had ever heard of Jabber, but these days
it is very close to hazardous for the health of the network.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/jdev/attachments/20090404/cac8fa3e/attachment.bin 

From mikemendel at gmail.com  Sat Apr  4 16:00:06 2009
From: mikemendel at gmail.com (mikemendel)
Date: Sat,  4 Apr 2009 16:00:06 -0500 (CDT)
Subject: [jdev] mikemendel has invited you to join SlideShare
Message-ID: <20090404210006.ACF9E21AD64@atlas.jabber.org>

An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/jdev/attachments/20090404/aa6fde85/attachment.htm 

From pendleto at movsoftware.com  Mon Apr  6 09:57:23 2009
From: pendleto at movsoftware.com (Stephen Pendleton)
Date: Mon, 6 Apr 2009 10:57:23 -0400
Subject: [jdev] update on XMPP location (wherein beer is offered)
In-Reply-To: <49D3BC1D.90504@buddycloud.com>
Message-ID: <9090DBE6366A4B5C8CEEC37CC2799F1C@movsoftware.com>

I can't seem to get this to work. For example I send:

<iq to="butler.buddycloud.com" type="get" xml:lang="en" id="location1">
	<locationquery xmlns="urn:xmpp:locationquery:0">
		<timestamp>2009-04-05T08:09:56Z</timestamp>
		<publish>true</publish>
		<reference>
			<id>262:07:51520:34124757</id>
			<type>cell</type>
			<signalstrength>88</signalstrength>
		</reference>		
	</locationquery>
	<locationquery xmlns="urn:xmpp:locationquery:0">
		<timestamp>2009-04-05T08:09:56Z</timestamp>
		<reference>
			<id>262:07:51520:34104756</id>
			<type>cell</type>
			<signalstrength>88</signalstrength>
		</reference>		
	</locationquery>
	<locationquery xmlns="urn:xmpp:locationquery:0">
		<timestamp>2009-04-05T08:09:56Z</timestamp>
		<reference>
			<id>262:07:51520:34084753</id>
			<type>cell</type>
			<signalstrength>88</signalstrength>
		</reference>		
	</locationquery>
</iq>
and I get back the placename OK. I then send the nearby places query and get
an error back:

<iq to="butler.buddycloud.com" type="get" id="nearbyplaces1">
	<command xmlns="http://jabber.org/protocol/commands"
node="location">
		<x xmlns="jabber:x:data" type="form">
			<field type="hidden" var="FORM_TYPE">
	
<value>buddycloud:location:places_near</value>
			</field>
		</x>
	</command>
</iq>

and get back:
<iq from="butler.buddycloud.com" to="spendleton at movsoftware.com/spark"
id="nearbyplaces1" type="error" xml:lang="en-GB">
	<command xmlns="http://jabber.org/protocol/commands"
node="location">
		<x xmlns="jabber:x:data" type="form">
			<field type="hidden" var="FORM_TYPE">
	
<value>buddycloud:location:places_near</value>
			</field>
		</x>
	</command>
<error code="500" type="wait"><internal-server-error
xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/><text
xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/></error></iq>


Also, I dont understand the <publish>true</publish> stanza. In the case
where I am sending cellids what is it publishing to my PEP node? Not my
lat/lon right, because you do not have lat/lon mappings from cellids to
lat/long coordinates and I dont have a placename published with that
lat/lon.

Also, if I remove or set the <publish> to <publish>false</publish> I get
back:

iq from="butler.buddycloud.com" to="spendleton at movsoftware.com/spark"
id="location31" type="result"><geoloc
xmlns="http://jabber.org/protocol/geoloc"
xml:lang="en"><accuracy>1000000</accuracy></geoloc></iq>

Not sure what this means.

Thanks
-----Original Message-----
From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] On Behalf Of
Simon Tennant
Sent: 04/01/2009 3:10 PM
To: Jabber/XMPP software development list
Subject: Re: [jdev] update on XMPP location (wherein beer is offered)


Stephen Pendleton wrote:
> I like this a lot. How does the "nearby" query work? Does it returned 
> bookmarked places that are owned by the submitting jid, or any 
> bookmarked place nearby? What is "cellpatternquality" mean?
A place can have one of two modes.

    * Public places are those that can be shared with other people. Eg
      my placemark for Starbucks would be useful to others.
    * Private places are those that will not be shared with others. For
      example my placemark called "Home sweet home" is probably not
      useful to others on the network (and/or I want it to be private to
      just me and only shared with my friends).

butler.buddycloud.com will only show public in a nearby query. These will be
public places from all users. Additionally you can subscribe to a place
which then places it on your own list of places that you are placed at in
the future.

CellPatternQuality reflects the certainty of the place.  How "distinct" it
is. For example when you are driving the location butler will be seeing lots
of new wifi and cell towers. Saving a placemark at that point will save it
but it will be a "blurry" pattern in the database. 
Better would be to wait a moment, submit a couple more location queries,
watch for the cellpatternquality to increase to 100% and then send a
placemark save stanza.  Then the butler will be far more likely to
accurately place you back at that point in the future.

> Also, how does the component push my location to my PEP node if I am 
> on another server? Would this be allowed by XMPP servers? I would be 
> interested in seeing these stanzas though to test it out.
Indeed for non-buddycloud.com domains PEP would not work. There are two
solutions for this that we are looking at. Either:

    * having the remote non buddycloud node publish their own pep node
      after getting a reply to their location query stanza or
    * granting publisher rights to butler.buddycloud.com on your own
      pubsub geoloc node and passing the address to this node as part of
      the location query. The query results would then be published on
      your behalf in XEP-0080 (user location) format as well as being
      returned to the client.

> There is another application we are working on that involves XEP-0255. 
> It currently supports what you are calling "beacon logs" stanzas to 
> return back postal addresses. The system uses a combination of wifi 
> access points/mobile
> towers to pinpoint your position and return back a lat/lon. It is very
> accurate in a populated area.
The butler does a best effort on the lookup of lat/long too and publishes it
as part of the XEP-0080 stack. I don't think we fill out the post code for
general locations (we do for known places) but this could presumably be
added with access to the right lat/long -> postcode mapping tables.  It's
not something that we have spent too much time on. Our main efforts in
butler development have focused on making location something social by
describing it as known places like home or work or "on the road in munich"
(travelling) or  "near  Jo's house" for example.

S.

-- 
Simon Tennant
Buddycloud
uk: +44 20 7043 6756               de: +49 89 420 955 854  
uk: +44 78 5335 6047               de: +49 17 8545 0880
email and xmpp: simon at buddycloud.com
http://buddycloud.com

_______________________________________________
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: JDev-unsubscribe at jabber.org
_______________________________________________



From helge at buddycloud.com  Mon Apr  6 13:33:27 2009
From: helge at buddycloud.com (Helge Timenes)
Date: Mon, 06 Apr 2009 20:33:27 +0200
Subject: [jdev] update on XMPP location (wherein beer is offered)
In-Reply-To: <9090DBE6366A4B5C8CEEC37CC2799F1C@movsoftware.com>
References: <9090DBE6366A4B5C8CEEC37CC2799F1C@movsoftware.com>
Message-ID: <49DA4AF7.1080806@buddycloud.com>

Stephen Pendleton wrote:
> I can't seem to get this to work. For example I send:
>
> <iq to="butler.buddycloud.com" type="get" xml:lang="en" id="location1">
> 	<locationquery xmlns="urn:xmpp:locationquery:0">
> 		<timestamp>2009-04-05T08:09:56Z</timestamp>
> 		<publish>true</publish>
> 		<reference>
> 			<id>262:07:51520:34124757</id>
> 			<type>cell</type>
> 			<signalstrength>88</signalstrength>
> 		</reference>		
> 	</locationquery>
> 	<locationquery xmlns="urn:xmpp:locationquery:0">
> 		<timestamp>2009-04-05T08:09:56Z</timestamp>
> 		<reference>
> 			<id>262:07:51520:34104756</id>
> 			<type>cell</type>
> 			<signalstrength>88</signalstrength>
> 		</reference>		
> 	</locationquery>
> 	<locationquery xmlns="urn:xmpp:locationquery:0">
> 		<timestamp>2009-04-05T08:09:56Z</timestamp>
> 		<reference>
> 			<id>262:07:51520:34084753</id>
> 			<type>cell</type>
> 			<signalstrength>88</signalstrength>
> 		</reference>		
> 	</locationquery>
> </iq>
>   
At the moment our server don't like multiple <locationquery> elements in 
an <iq>. There is no particularly good reason for this and I will fix it.

> and I get back the placename OK. I then send the nearby places query and get
> an error back:
>
> <iq to="butler.buddycloud.com" type="get" id="nearbyplaces1">
> 	<command xmlns="http://jabber.org/protocol/commands"
> node="location">
> 		<x xmlns="jabber:x:data" type="form">
> 			<field type="hidden" var="FORM_TYPE">
> 	
> <value>buddycloud:location:places_near</value>
> 			</field>
> 		</x>
> 	</command>
> </iq>
>
> and get back:
> <iq from="butler.buddycloud.com" to="spendleton at movsoftware.com/spark"
> id="nearbyplaces1" type="error" xml:lang="en-GB">
> 	<command xmlns="http://jabber.org/protocol/commands"
> node="location">
> 		<x xmlns="jabber:x:data" type="form">
> 			<field type="hidden" var="FORM_TYPE">
> 	
> <value>buddycloud:location:places_near</value>
> 			</field>
> 		</x>
> 	</command>
> <error code="500" type="wait"><internal-server-error
> xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/><text
> xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/></error></iq>
>
>
>   
Something wrong was probably not right there (!) Possibly to do with the 
above.
> Also, I dont understand the <publish>true</publish> stanza. In the case
> where I am sending cellids what is it publishing to my PEP node? Not my
> lat/lon right, because you do not have lat/lon mappings from cellids to
> lat/long coordinates and I dont have a placename published with that
> lat/lon.
>   
It will publish as much info as can be derived from your references. We 
do have a rudimentary cell to lat/lon database, and if a match is found 
it wil use this to derive your coordinates. If not it will default to 
the center of your country (derived from MCC) associated with a huuuuge 
error. From lat/lon it will try to obtain region, city and area names 
(with a little help from geonames.org).

Note that the publish will most likely fail, since your host server will 
propably let our server publish to your PEP node on your behalf. Some 
configuration might be needed for this to work I believe.
> Also, if I remove or set the <publish> to <publish>false</publish> I get
> back:
>
> iq from="butler.buddycloud.com" to="spendleton at movsoftware.com/spark"
> id="location31" type="result"><geoloc
> xmlns="http://jabber.org/protocol/geoloc"
> xml:lang="en"><accuracy>1000000</accuracy></geoloc></iq>
>
> Not sure what this means.
>   
This is probably related to your error above. Some how no results could 
be found (even so it suggest an error for your location had it been 
found. Er...  right)
> Thanks
>   
Your're welcome

From gnauck at ag-software.de  Mon Apr  6 14:10:58 2009
From: gnauck at ag-software.de (Alexander Gnauck)
Date: Mon, 06 Apr 2009 21:10:58 +0200
Subject: [jdev] XSF membership application period Q2/2009
Message-ID: <49DA53C2.90006@ag-software.de>

The XMPP Standards Foundation (XSF) is currently holding its quarterly 
membership application period:
http://wiki.xmpp.org/web/Membership_Applications_April_2009

Applications are encouraged from developers and others who are actively 
involved in the Jabber/XMPP community. To apply, create a page about 
yourself on the wiki.

If you don't have a wiki account, send your name, preferred nickname and
email address to me or one of the other Sysops:
http://wiki.xmpp.org/index.php/Sysops

The application period ends on 22th April 2009 23:59h UTC, so apply today!

Regards,
Alex
--
Alexander Gnauck
xmpp:gnauck at jabber.org

From waqas20 at gmail.com  Mon Apr  6 14:27:08 2009
From: waqas20 at gmail.com (Waqas Hussain)
Date: Tue, 7 Apr 2009 00:27:08 +0500
Subject: [jdev] update on XMPP location (wherein beer is offered)
In-Reply-To: <49DA4AF7.1080806@buddycloud.com>
References: <9090DBE6366A4B5C8CEEC37CC2799F1C@movsoftware.com>
	<49DA4AF7.1080806@buddycloud.com>
Message-ID: <7fc4fa880904061227k7a31a66fxea5375a3d196af5b@mail.gmail.com>

On Mon, Apr 6, 2009 at 11:33 PM, Helge Timenes <helge at buddycloud.com> wrote:
> Stephen Pendleton wrote:
>> I can't seem to get this to work. For example I send:
>>
>> <iq to="butler.buddycloud.com" type="get" xml:lang="en" id="location1">
>> ? ? ? <locationquery xmlns="urn:xmpp:locationquery:0">
>> ? ? ? ? ? ? ? <timestamp>2009-04-05T08:09:56Z</timestamp>
>> ? ? ? ? ? ? ? <publish>true</publish>
>> ? ? ? ? ? ? ? <reference>
>> ? ? ? ? ? ? ? ? ? ? ? <id>262:07:51520:34124757</id>
>> ? ? ? ? ? ? ? ? ? ? ? <type>cell</type>
>> ? ? ? ? ? ? ? ? ? ? ? <signalstrength>88</signalstrength>
>> ? ? ? ? ? ? ? </reference>
>> ? ? ? </locationquery>
>> ? ? ? <locationquery xmlns="urn:xmpp:locationquery:0">
>> ? ? ? ? ? ? ? <timestamp>2009-04-05T08:09:56Z</timestamp>
>> ? ? ? ? ? ? ? <reference>
>> ? ? ? ? ? ? ? ? ? ? ? <id>262:07:51520:34104756</id>
>> ? ? ? ? ? ? ? ? ? ? ? <type>cell</type>
>> ? ? ? ? ? ? ? ? ? ? ? <signalstrength>88</signalstrength>
>> ? ? ? ? ? ? ? </reference>
>> ? ? ? </locationquery>
>> ? ? ? <locationquery xmlns="urn:xmpp:locationquery:0">
>> ? ? ? ? ? ? ? <timestamp>2009-04-05T08:09:56Z</timestamp>
>> ? ? ? ? ? ? ? <reference>
>> ? ? ? ? ? ? ? ? ? ? ? <id>262:07:51520:34084753</id>
>> ? ? ? ? ? ? ? ? ? ? ? <type>cell</type>
>> ? ? ? ? ? ? ? ? ? ? ? <signalstrength>88</signalstrength>
>> ? ? ? ? ? ? ? </reference>
>> ? ? ? </locationquery>
>> </iq>
>>
> At the moment our server don't like multiple <locationquery> elements in
> an <iq>. There is no particularly good reason for this and I will fix it.
>

There is a particularly good reason for this: IQ gets and sets are
only allowed to have a single child.

Don't 'fix' this, because accepting multiple IQ children would break
the XMPP spec.

--
Waqas Hussain

From helge at buddycloud.com  Mon Apr  6 14:40:49 2009
From: helge at buddycloud.com (Helge Timenes)
Date: Mon, 06 Apr 2009 21:40:49 +0200
Subject: [jdev] update on XMPP location (wherein beer is offered)
In-Reply-To: <7fc4fa880904061227k7a31a66fxea5375a3d196af5b@mail.gmail.com>
References: <9090DBE6366A4B5C8CEEC37CC2799F1C@movsoftware.com>	<49DA4AF7.1080806@buddycloud.com>
	<7fc4fa880904061227k7a31a66fxea5375a3d196af5b@mail.gmail.com>
Message-ID: <49DA5AC1.6050602@buddycloud.com>

Waqas Hussain wrote:
> On Mon, Apr 6, 2009 at 11:33 PM, Helge Timenes <helge at buddycloud.com> wrote:
>   
>> Stephen Pendleton wrote:
>>     
>>> I can't seem to get this to work. For example I send:
>>>
>>> <iq to="butler.buddycloud.com" type="get" xml:lang="en" id="location1">
>>>       <locationquery xmlns="urn:xmpp:locationquery:0">
>>>               <timestamp>2009-04-05T08:09:56Z</timestamp>
>>>               <publish>true</publish>
>>>               <reference>
>>>                       <id>262:07:51520:34124757</id>
>>>                       <type>cell</type>
>>>                       <signalstrength>88</signalstrength>
>>>               </reference>
>>>       </locationquery>
>>>       <locationquery xmlns="urn:xmpp:locationquery:0">
>>>               <timestamp>2009-04-05T08:09:56Z</timestamp>
>>>               <reference>
>>>                       <id>262:07:51520:34104756</id>
>>>                       <type>cell</type>
>>>                       <signalstrength>88</signalstrength>
>>>               </reference>
>>>       </locationquery>
>>>       <locationquery xmlns="urn:xmpp:locationquery:0">
>>>               <timestamp>2009-04-05T08:09:56Z</timestamp>
>>>               <reference>
>>>                       <id>262:07:51520:34084753</id>
>>>                       <type>cell</type>
>>>                       <signalstrength>88</signalstrength>
>>>               </reference>
>>>       </locationquery>
>>> </iq>
>>>
>>>       
>> At the moment our server don't like multiple <locationquery> elements in
>> an <iq>. There is no particularly good reason for this and I will fix it.
>>
>>     
>
> There is a particularly good reason for this: IQ gets and sets are
> only allowed to have a single child.
>
> Don't 'fix' this, because accepting multiple IQ children would break
> the XMPP spec.
>
>   
Right, silly of me. Fix cancelled.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/jdev/attachments/20090406/dd6fc296/attachment.htm 

From fippo at goodadvice.pages.de  Mon Apr  6 14:42:49 2009
From: fippo at goodadvice.pages.de (Philipp Hancke)
Date: Mon, 06 Apr 2009 21:42:49 +0200
Subject: [jdev] update on XMPP location (wherein beer is offered)
In-Reply-To: <7fc4fa880904061227k7a31a66fxea5375a3d196af5b@mail.gmail.com>
References: <9090DBE6366A4B5C8CEEC37CC2799F1C@movsoftware.com>	<49DA4AF7.1080806@buddycloud.com>
	<7fc4fa880904061227k7a31a66fxea5375a3d196af5b@mail.gmail.com>
Message-ID: <49DA5B39.8050905@goodadvice.pages.de>

Waqas Hussain wrote:
> There is a particularly good reason for this: IQ gets and sets are
> only allowed to have a single child.
> 
> Don't 'fix' this, because accepting multiple IQ children would break
> the XMPP spec.

and because XEP 0255 - example 7 shows the right way to do it.

From pendleto at movsoftware.com  Mon Apr  6 15:12:09 2009
From: pendleto at movsoftware.com (Stephen Pendleton)
Date: Mon, 6 Apr 2009 16:12:09 -0400
Subject: [jdev] update on XMPP location (wherein beer is offered)
In-Reply-To: <7fc4fa880904061227k7a31a66fxea5375a3d196af5b@mail.gmail.com>
Message-ID: <693A5CF4B33B4EBBB0913659D3F8F147@movsoftware.com>

My mistake. I meant to say I sent:

<iq to="butler.buddycloud.com" type="get" xml:lang="en" id="location1">
	<locationquery xmlns="urn:xmpp:locationquery:0">
		<reference>
			<id>262:07:51520:34124757</id>
			<type>cell</type>
			<signalstrength>88</signalstrength>
		</reference>		
		<reference>
			<id>262:07:51520:34104756</id>
			<type>cell</type>
			<signalstrength>88</signalstrength>
		</reference>		
		<reference>
			<id>262:07:51520:34084753</id>
			<type>cell</type>
			<signalstrength>88</signalstrength>
		</reference>		
	</locationquery>
</iq>

-----Original Message-----
From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] On Behalf Of
Waqas Hussain
Sent: 04/06/2009 3:27 PM
To: Jabber/XMPP software development list
Subject: Re: [jdev] update on XMPP location (wherein beer is offered)


On Mon, Apr 6, 2009 at 11:33 PM, Helge Timenes <helge at buddycloud.com> wrote:
> Stephen Pendleton wrote:
>> I can't seem to get this to work. For example I send:
>>
>> <iq to="butler.buddycloud.com" type="get" xml:lang="en" 
>> id="location1">
>> ? ? ? <locationquery xmlns="urn:xmpp:locationquery:0">
>> ? ? ? ? ? ? ? <timestamp>2009-04-05T08:09:56Z</timestamp>
>> ? ? ? ? ? ? ? <publish>true</publish>
>> ? ? ? ? ? ? ? <reference>
>> ? ? ? ? ? ? ? ? ? ? ? <id>262:07:51520:34124757</id>
>> ? ? ? ? ? ? ? ? ? ? ? <type>cell</type>
>> ? ? ? ? ? ? ? ? ? ? ? <signalstrength>88</signalstrength>
>> ? ? ? ? ? ? ? </reference>
>> ? ? ? </locationquery>
>> ? ? ? <locationquery xmlns="urn:xmpp:locationquery:0">
>> ? ? ? ? ? ? ? <timestamp>2009-04-05T08:09:56Z</timestamp>
>> ? ? ? ? ? ? ? <reference>
>> ? ? ? ? ? ? ? ? ? ? ? <id>262:07:51520:34104756</id>
>> ? ? ? ? ? ? ? ? ? ? ? <type>cell</type>
>> ? ? ? ? ? ? ? ? ? ? ? <signalstrength>88</signalstrength>
>> ? ? ? ? ? ? ? </reference>
>> ? ? ? </locationquery>
>> ? ? ? <locationquery xmlns="urn:xmpp:locationquery:0">
>> ? ? ? ? ? ? ? <timestamp>2009-04-05T08:09:56Z</timestamp>
>> ? ? ? ? ? ? ? <reference>
>> ? ? ? ? ? ? ? ? ? ? ? <id>262:07:51520:34084753</id>
>> ? ? ? ? ? ? ? ? ? ? ? <type>cell</type>
>> ? ? ? ? ? ? ? ? ? ? ? <signalstrength>88</signalstrength>
>> ? ? ? ? ? ? ? </reference>
>> ? ? ? </locationquery>
>> </iq>
>>
> At the moment our server don't like multiple <locationquery> elements 
> in an <iq>. There is no particularly good reason for this and I will 
> fix it.
>

There is a particularly good reason for this: IQ gets and sets are only
allowed to have a single child.

Don't 'fix' this, because accepting multiple IQ children would break the
XMPP spec.

--
Waqas Hussain
_______________________________________________
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: JDev-unsubscribe at jabber.org
_______________________________________________



From stpeter at stpeter.im  Mon Apr  6 23:20:45 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 06 Apr 2009 22:20:45 -0600
Subject: [jdev] jabber disk ?
In-Reply-To: <200903222325.n2MNPGCE017257@zogzog.maillard.mobi>
References: <200903222325.n2MNPGCE017257@zogzog.maillard.mobi>
Message-ID: <49DAD49D.2000707@stpeter.im>

On 3/22/09 5:25 PM, Xavier Maillard wrote:
> Hi,
> 
> I am writting a text editor with the aim to publish
> notes/articles/whatever over XMPP. I have all the basic editor
> stuff working and now has come the time to choose how to
> effectively "publish" these texts.
> 
> My goal behind this, is to have access to my notes anywhere at
> anytime. I am not sure what the best method I should choose to
> store all this stuff. I know there were tries to have webdav over
> XMPP, I know there is pubsub (which has my preference)  and
> lately I felt upon something called "jabdisk". I am looking for
> information about the later.
> 
> OTOH, if you have any idea on a global storage strategy for my
> client, feel free to share them :)
> 
> My main interest in writing this software is to be able to run a
> "jabber site" (aka a website) totally via XMPP and particulary a
> "XMPP wiki".

Why? Isn't that what HTTP is for?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/jdev/attachments/20090406/5640f1a3/attachment-0001.bin 

From christopher.zorn at gmail.com  Wed Apr  8 10:29:08 2009
From: christopher.zorn at gmail.com (Christopher Zorn)
Date: Wed, 8 Apr 2009 11:29:08 -0400
Subject: [jdev] ANN. Couchdb Backend
Message-ID: <149014b90904080829g642de4e4l684b530a0a6e7cbd@mail.gmail.com>

Just wanted to announce that I started a couchdb backend for ejabberd.

I did not create a ticket because I did not know if it fit. Also, it would
be nice to see how many people are interested in it before it is formal.

It is located on github.

http://thetofu.com/archive/ejabberd_couchdb_20090407.html
http://github.com/twonds/ejabberd_couchdb/tree/master

Relax and enjoy. ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/jdev/attachments/20090408/61894de8/attachment.htm 

From thiranjith at gmail.com  Wed Apr  8 14:26:12 2009
From: thiranjith at gmail.com (Thiranjith .)
Date: Thu, 9 Apr 2009 07:26:12 +1200
Subject: [jdev] Using XMPP to talk to a mobile client
Message-ID: <2ec5902e0904081226v734582e9ib30ebca6c2f7ce18@mail.gmail.com>

Hi,

Can we use XMPP to talk to a client on a mobile device (e.g. PDA/ mobile
phone) that is connected to the internet using 3G? From what I understand,
phones' end-point IP changes as they move around, and generally they are
behind the network operator's (At&T, Vodafone etc) firewall.

Say that user 'A' sends a message to our mobile client. From what I
understand, the message will go through the XMPP server (e.g. Jabber.org or
our own) to find where our client is, so it can route the message. How would
the XMPP server know where to find our client in the place? The IP our
client used when registering with the server could be different now because
it could have moved around.

Does the mobile client need to periodically notify the server about its IP?

From stpeter at stpeter.im  Wed Apr  8 14:44:11 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 08 Apr 2009 13:44:11 -0600
Subject: [jdev] Monthly XMPP Meeting #2
Message-ID: <49DCFE8B.3080201@stpeter.im>

Although I never sent out minutes from the first "Monthly XMPP Meeting",
I think it would be productive to hold another meeting again soon. I
propose next Tuesday, April 14, at 20:00 UTC (check your local times!)
in the jdev at conference.jabber.org room.

See you there!

Peter

P.S. Maybe I'll get a change to write up the minutes from MXM #1 before
then:

http://logs.jabber.org/jdev at conference.jabber.org/2009-03-12.html


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/jdev/attachments/20090408/e8235b02/attachment.bin 

From fabio.forno at gmail.com  Wed Apr  8 16:37:47 2009
From: fabio.forno at gmail.com (Fabio Forno)
Date: Wed, 8 Apr 2009 23:37:47 +0200
Subject: [jdev] Using XMPP to talk to a mobile client
In-Reply-To: <2ec5902e0904081226v734582e9ib30ebca6c2f7ce18@mail.gmail.com>
References: <2ec5902e0904081226v734582e9ib30ebca6c2f7ce18@mail.gmail.com>
Message-ID: <2fd53c3a0904081437q2d364a2w8e0b69d5b404a00@mail.gmail.com>

On Wed, Apr 8, 2009 at 9:26 PM, Thiranjith . <thiranjith at gmail.com> wrote:
> Hi,
>
> Can we use XMPP to talk to a client on a mobile device (e.g. PDA/ mobile
> phone) that is connected to the internet using 3G? From what I understand,
> phones' end-point IP changes as they move around, and generally they are
> behind the network operator's (At&T, Vodafone etc) firewall.
>
> Say that user 'A' sends a message to our mobile client. From what I
> understand, the message will go through the XMPP server (e.g. Jabber.org or
> our own) to find where our client is, so it can route the message. How would
> the XMPP server know where to find our client in the place? The IP our
> client used when registering with the server could be different now because
> it could have moved around.

As far as you are online with your client a socket is being kept open
with the server, thus allowing to push stanzas to your device. No need
to communicate your IP, just listen for incoming messages. You may try
one of the several clients listed here
http://xmpp.org/software/clients.shtml#mobile

Most networks will maintain your IP while moving to different cells,
and if you get disconnected it's up to the client to reopen a session
with the server

The situation is different while you are disconnected. In that case
the server stores the messages in the offline storage until the client
goes online

If you have urgent messages you can use an SMS for automatically
waking up the client, however this is a service that has a cost


> Does the mobile client need to periodically notify the server about its IP?
> From what I understand, the BOSH technique described in
> http://xmpp.org/extensions/xep-0124.html#intro is meant to address this, but
> it seems to work only if the entity behind the firewall initiate the
> connection first (in this case, the client running within the mobile phone).

BOSH likes tecniques are just used to pass through proxies or run
clients in web browsers. They may be used in order to improve
connection reliability, but a new and better method (xep-0198) is
being defined for this purpose.

-- 
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: ff at jabber.bluendo.com

From jonathan.dickinson at k2.com  Thu Apr  9 02:28:24 2009
From: jonathan.dickinson at k2.com (Jonathan Dickinson)
Date: Thu, 9 Apr 2009 09:28:24 +0200
Subject: [jdev] Using XMPP to talk to a mobile client
In-Reply-To: <2fd53c3a0904081437q2d364a2w8e0b69d5b404a00@mail.gmail.com>
References: <2ec5902e0904081226v734582e9ib30ebca6c2f7ce18@mail.gmail.com>
	<2fd53c3a0904081437q2d364a2w8e0b69d5b404a00@mail.gmail.com>
Message-ID: <A790BE8D83ECC3469047C2E344EABE61027C6442096B@zamail01.k2workflow.com>

> -----Original Message-----
> From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] On
> Behalf Of Fabio Forno
> Sent: 08 April 2009 11:38 PM
> To: Jabber/XMPP software development list
> Subject: Re: [jdev] Using XMPP to talk to a mobile client
> 
> On Wed, Apr 8, 2009 at 9:26 PM, Thiranjith . <thiranjith at gmail.com>
> wrote:
> > Hi,
> >
> > Can we use XMPP to talk to a client on a mobile device (e.g. PDA/
> mobile
> > phone) that is connected to the internet using 3G? From what I
> understand,
> > phones' end-point IP changes as they move around, and generally they
> are
> > behind the network operator's (At&T, Vodafone etc) firewall.
> >

IPv6 is supposed to address situations in regard to mobile devices. Although I am not entirely sure how well the technologies have been deployed. IIRC most mobile operators use NAT to connect clients to the internet, this means that the NAT will do what it can to keep your socket connections alive - in other words, mobile devices are less reliable (because they can lose signal entirely), but still completely viable (because the operators generally have this kind of stuff in mind).

My Windows Mobile phone has IPv6 and I have been able to access the IPv6 test website - if it works in a backwards country like South Africa it's gotta work in America and the UK!!!
 
> > Does the mobile client need to periodically notify the server about
> its IP?

No and yes. As I said this should be handled by your operator's NAT: test the system and find out (connect to a XMPP server and go on a road trip). If it isn't you should definitely raise a stink.

Yes in terms that, primarily, if your public IP (i.e. one of your operator's IP addresses) changes chances are you are going to get clean disconnected. If this happens your client should reconnect automatically - and as a side effect of this the server gets your new IP.

> 
> --
> Fabio Forno, Ph.D.
> Bluendo srl http://www.bluendo.com
> jabber id: ff at jabber.bluendo.com
> _______________________________________________
> JDev mailing list
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________

From mridulm80 at yahoo.com  Thu Apr  9 06:20:26 2009
From: mridulm80 at yahoo.com (Mridul Muralidharan)
Date: Thu, 9 Apr 2009 16:50:26 +0530 (IST)
Subject: [jdev] Using XMPP to talk to a mobile client
Message-ID: <907698.28410.qm@web95414.mail.in2.yahoo.com>




Just to mention, BOSH does not have any same client IP requirement/restriction.

And unlike tcp binding of xmpp - where session is terminated if disconnected, BOSH does handle disconnects in its design.

The only requirements would be -

a) ability of the client to connect back before the session/idle timeout.
b) BOSH gateway not going down.
c) BOSH client not going down.

b and c are mentioned - so that the session state (rid, etc) is not lost.

Regards,
Mridul



--- On Thu, 9/4/09, Jonathan Dickinson <jonathan.dickinson at k2.com> wrote:

> From: Jonathan Dickinson <jonathan.dickinson at k2.com>
> Subject: Re: [jdev] Using XMPP to talk to a mobile client
> To: "Jabber/XMPP software development list" <jdev at jabber.org>
> Date: Thursday, 9 April, 2009, 12:58 PM
> > -----Original Message-----
> > From: jdev-bounces at jabber.org
> [mailto:jdev-bounces at jabber.org]
> On
> > Behalf Of Fabio Forno
> > Sent: 08 April 2009 11:38 PM
> > To: Jabber/XMPP software development list
> > Subject: Re: [jdev] Using XMPP to talk to a mobile
> client
> > 
> > On Wed, Apr 8, 2009 at 9:26 PM, Thiranjith . <thiranjith at gmail.com>
> > wrote:
> > > Hi,
> > >
> > > Can we use XMPP to talk to a client on a mobile
> device (e.g. PDA/
> > mobile
> > > phone) that is connected to the internet using
> 3G? From what I
> > understand,
> > > phones' end-point IP changes as they move around,
> and generally they
> > are
> > > behind the network operator's (At&T, Vodafone
> etc) firewall.
> > >
> 
> IPv6 is supposed to address situations in regard to mobile
> devices. Although I am not entirely sure how well the
> technologies have been deployed. IIRC most mobile operators
> use NAT to connect clients to the internet, this means that
> the NAT will do what it can to keep your socket connections
> alive - in other words, mobile devices are less reliable
> (because they can lose signal entirely), but still
> completely viable (because the operators generally have this
> kind of stuff in mind).
> 
> My Windows Mobile phone has IPv6 and I have been able to
> access the IPv6 test website - if it works in a backwards
> country like South Africa it's gotta work in America and the
> UK!!!
>  
> > > Does the mobile client need to periodically
> notify the server about
> > its IP?
> 
> No and yes. As I said this should be handled by your
> operator's NAT: test the system and find out (connect to a
> XMPP server and go on a road trip). If it isn't you should
> definitely raise a stink.
> 
> Yes in terms that, primarily, if your public IP (i.e. one
> of your operator's IP addresses) changes chances are you are
> going to get clean disconnected. If this happens your client
> should reconnect automatically - and as a side effect of
> this the server gets your new IP.
> 
> > 
> > --
> > Fabio Forno, Ph.D.
> > Bluendo srl http://www.bluendo.com
> > jabber id: ff at jabber.bluendo.com
> > _______________________________________________
> > JDev mailing list
> > Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> > Info: http://mail.jabber.org/mailman/listinfo/jdev
> > Unsubscribe: JDev-unsubscribe at jabber.org
> > _______________________________________________
> _______________________________________________
> JDev mailing list
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________
> 


      Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/


From stpeter at stpeter.im  Thu Apr  9 09:41:22 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 09 Apr 2009 08:41:22 -0600
Subject: [jdev] Using XMPP to talk to a mobile client
In-Reply-To: <907698.28410.qm@web95414.mail.in2.yahoo.com>
References: <907698.28410.qm@web95414.mail.in2.yahoo.com>
Message-ID: <49DE0912.4030405@stpeter.im>

On 4/9/09 5:20 AM, Mridul Muralidharan wrote:
> 
> Just to mention, BOSH does not have any same client IP
> requirement/restriction.
> 
> And unlike tcp binding of xmpp - where session is terminated if
> disconnected, BOSH does handle disconnects in its design.
> 
> The only requirements would be -
> 
> a) ability of the client to connect back before the session/idle
> timeout. 

And that's part of XEP-0198. Updated version today. :)

> b) BOSH gateway not going down. 
> c) BOSH client not going down.
> 
> b and c are mentioned - so that the session state (rid, etc) is not
> lost.

Sure, if the client or server dies then state will (probably) be lost.
On the server side, people do some creative things here for high
availability / fail-over.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/jdev/attachments/20090409/5f740341/attachment-0001.bin 

From mridulm80 at yahoo.com  Thu Apr  9 11:33:25 2009
From: mridulm80 at yahoo.com (Mridul Muralidharan)
Date: Thu, 9 Apr 2009 22:03:25 +0530 (IST)
Subject: [jdev] Using XMPP to talk to a mobile client
Message-ID: <579761.84324.qm@web95414.mail.in2.yahoo.com>




--- On Thu, 9/4/09, Peter Saint-Andre <stpeter at stpeter.im> wrote:

> From: Peter Saint-Andre <stpeter at stpeter.im>
> Subject: Re: [jdev] Using XMPP to talk to a mobile client
> To: "Jabber/XMPP software development list" <jdev at jabber.org>
> Date: Thursday, 9 April, 2009, 8:11 PM
> On 4/9/09 5:20 AM, Mridul
> Muralidharan wrote:
> > 
> > Just to mention, BOSH does not have any same client
> IP
> > requirement/restriction.
> > 
> > And unlike tcp binding of xmpp - where session is
> terminated if
> > disconnected, BOSH does handle disconnects in its
> design..
> > 
> > The only requirements would be -
> > 
> > a) ability of the client to connect back before the
> session/idle
> > timeout. 
> 
> And that's part of XEP-0198. Updated version today. :)


Had not gone over it before, looks quite interesting - will add to my reading list ...


> 
> > b) BOSH gateway not going down. 
> > c) BOSH client not going down.
> > 
> > b and c are mentioned - so that the session state
> (rid, etc) is not
> > lost.
> 
> Sure, if the client or server dies then state will
> (probably) be lost.
> On the server side, people do some creative things here for
> high
> availability / fail-over.


Yes, I am thinking of something along those lines.
Will ping you about some queries regarding this and how it relates to stream resumption later on btw :-)

Thanks,
Mridul

> 
> Peter
> 
> -- 
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> -----Inline Attachment Follows-----
> 
> _______________________________________________
> JDev mailing list
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________
> 


      Share files, take polls, and make new friends - all under one roof. Go to http://in.promos.yahoo.com/groups/


From gnauck at ag-software.de  Thu Apr  9 12:41:48 2009
From: gnauck at ag-software.de (Alexander Gnauck)
Date: Thu, 09 Apr 2009 19:41:48 +0200
Subject: [jdev] Using XMPP to talk to a mobile client
In-Reply-To: <907698.28410.qm@web95414.mail.in2.yahoo.com>
References: <907698.28410.qm@web95414.mail.in2.yahoo.com>
Message-ID: <grlc0r$nl9$1@ger.gmane.org>

Mridul Muralidharan wrote:
> 
> 
> Just to mention, BOSH does not have any same client IP requirement/restriction.
> 
> And unlike tcp binding of xmpp - where session is terminated if disconnected, BOSH does handle disconnects in its design.
> 
> The only requirements would be -
> 
> a) ability of the client to connect back before the session/idle timeout.
> b) BOSH gateway not going down.
> c) BOSH client not going down.
> 
> b and c are mentioned - so that the session state (rid, etc) is not lost.

I have a much better experience with sockets on Mobile devices than with 
BOSH. Of course this also depends how reliable you Mobile network is, 
but in Europe its very good, and sockets works very well.

Regards,
Alex
--
Alexander Gnauck
http://www.ag-software.de
xmpp:gnauck at jabber.org


From fabio.forno at gmail.com  Thu Apr  9 14:04:48 2009
From: fabio.forno at gmail.com (Fabio Forno)
Date: Thu, 9 Apr 2009 21:04:48 +0200
Subject: [jdev] Using XMPP to talk to a mobile client
In-Reply-To: <grlc0r$nl9$1@ger.gmane.org>
References: <907698.28410.qm@web95414.mail.in2.yahoo.com>
	<grlc0r$nl9$1@ger.gmane.org>
Message-ID: <2fd53c3a0904091204r54beb404v7b331fd31a0ca227@mail.gmail.com>

On Thu, Apr 9, 2009 at 7:41 PM, Alexander Gnauck <gnauck at ag-software.de> wrote:
>
> I have a much better experience with sockets on Mobile devices than with
> BOSH. Of course this also depends how reliable you Mobile network is,
> but in Europe its very good, and sockets works very well.

Just for curisioty: bosh using the phone HTTP apis or implementing the
whole HTTP requests ?

-- 
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: ff at jabber.bluendo.com

From elghinn at free.fr  Fri Apr 10 00:05:38 2009
From: elghinn at free.fr (=?ISO-8859-15?Q?Ana=EBl_Verrier?=)
Date: Fri, 10 Apr 2009 07:05:38 +0200
Subject: [jdev] xmppony 0.1 is released!
Message-ID: <49DED3A2.1030608@free.fr>

Hi,

I'm thrilled to announce the release of xmppony 0.1.

xmppony is an XMPP library released under GNU GPLv3. It's a fork of xmpppy, 
which was in turn a fork of jabber.py.

Why a fork? Because xmpppy was almost dead in the last 2 years. Because there 
are so many things which do not suit me (like the lack of PEP 8-compliance, the 
lack of file transfer support, the coding style, the hierarchy of the code, the 
"plugin" system, the simulation of heritage, etc.).


This first release is a drop-in replacement for xmpppy, with some bugs fixed and 
file transfer added, but next releases will swap a lot more things around.


Download xmppony 0.1:
http://xmppony.last-exile.org/sources/xmppony-0.1.tar.bz2

SVN repository:
http://svn.last-exile.org/xmppony/

Browse SVN repository:
http://trac.last-exile.org/xmppony/browser

Website:
http://xmppony.last-exile.org/

Jabber room:
last-exile at muc.last-exile.org


Enjoy the release.


--
Ana?l Verrier
xmpp:elghinn at last-exile.org
GPG: 1024D/65B95D84

From norman at rasmussen.co.za  Fri Apr 10 04:46:47 2009
From: norman at rasmussen.co.za (Norman Rasmussen)
Date: Fri, 10 Apr 2009 11:46:47 +0200
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <49DED3A2.1030608@free.fr>
References: <49DED3A2.1030608@free.fr>
Message-ID: <5b698f5a0904100246t3a8f569dja688cb2f88f4d7a8@mail.gmail.com>

On Fri, Apr 10, 2009 at 7:05 AM, Ana?l Verrier <elghinn at free.fr> wrote:

> Why a fork? Because xmpppy was almost dead in the last 2 years. Because
> there
> are so many things which do not suit me (like the lack of PEP 8-compliance,
> the
> lack of file transfer support, the coding style, the hierarchy of the code,
> the
> "plugin" system, the simulation of heritage, etc.).
>

As one of the co-maintainers of xmpp.py, why is this the first time i've
heard of this?  Alexey has recently contacted me to say that he's got time
to work on xmpp.py fixing bugs, etc, and was due to release 0.5rc1 soon.

I have not yet reviewed the differences, but would you be interested in
feeding back your changes to xmpp.py?

-- 
- Norman Rasmussen
- Email: norman at rasmussen.co.za
- Home page: http://norman.rasmussen.co.za/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/jdev/attachments/20090410/135510b0/attachment.htm 

From steve-e at h3c.de  Fri Apr 10 06:30:48 2009
From: steve-e at h3c.de (Stephan Erb)
Date: Fri, 10 Apr 2009 13:30:48 +0200
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <49DED3A2.1030608@free.fr>
References: <49DED3A2.1030608@free.fr>
Message-ID: <1239363048.5108.6.camel@localhost.localdomain>

Hey,

Gajim has forked xmpppy as well. I guess the main difference is a switch
to non-blocking sockets and the implementation of BOSH.

Maybe there is a chance here to streamline all those different efforts.

Best,
steve-e


On Fri, 2009-04-10 at 07:05 +0200, Ana?l Verrier wrote:
> Hi,
> 
> I'm thrilled to announce the release of xmppony 0.1.
> 
> xmppony is an XMPP library released under GNU GPLv3. It's a fork of xmpppy, 
> which was in turn a fork of jabber.py.
> 
> Why a fork? Because xmpppy was almost dead in the last 2 years. Because there 
> are so many things which do not suit me (like the lack of PEP 8-compliance, the 
> lack of file transfer support, the coding style, the hierarchy of the code, the 
> "plugin" system, the simulation of heritage, etc.).
> 
> 
> This first release is a drop-in replacement for xmpppy, with some bugs fixed and 
> file transfer added, but next releases will swap a lot more things around.
> 
> 
> Download xmppony 0.1:
> http://xmppony.last-exile.org/sources/xmppony-0.1.tar.bz2
> 
> SVN repository:
> http://svn.last-exile.org/xmppony/
> 
> Browse SVN repository:
> http://trac.last-exile.org/xmppony/browser
> 
> Website:
> http://xmppony.last-exile.org/
> 
> Jabber room:
> last-exile at muc.last-exile.org
> 
> 
> Enjoy the release.
> 
> 
> --
> Ana?l Verrier
> xmpp:elghinn at last-exile.org
> GPG: 1024D/65B95D84
> _______________________________________________
> JDev mailing list
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________

From asterix at lagaule.org  Fri Apr 10 06:40:13 2009
From: asterix at lagaule.org (Yann Leboulanger)
Date: Fri, 10 Apr 2009 13:40:13 +0200
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <1239363048.5108.6.camel@localhost.localdomain>
References: <49DED3A2.1030608@free.fr>
	<1239363048.5108.6.camel@localhost.localdomain>
Message-ID: <49DF301D.6070907@lagaule.org>

Stephan Erb a ?crit :
> Hey,
> 
> Gajim has forked xmpppy as well. I guess the main difference is a switch
> to non-blocking sockets and the implementation of BOSH.
> 
> Maybe there is a chance here to streamline all those different efforts.
> 
> Best,
> steve-e

That would be awsome, but I think the diff between Gajim fork and xmpppy is:

-*
+*

We re-arranged all files recently. So it will be a lot of work.

From wolf.heiner at googlemail.com  Fri Apr 10 07:26:47 2009
From: wolf.heiner at googlemail.com (Heiner Wolf)
Date: Fri, 10 Apr 2009 14:26:47 +0200
Subject: [jdev] jabber disk ?
In-Reply-To: <200903222325.n2MNPGCE017257@zogzog.maillard.mobi>
References: <200903222325.n2MNPGCE017257@zogzog.maillard.mobi>
Message-ID: <5f303cb80904100526i24671281tda272b751bfe3055@mail.gmail.com>

Hi,

Sometimes I think, that XMPP-iq-get/result does the same as
HTTP-request/response only better, because the client stays connected
and the server network does the routing including again persistent
managed connections. Beyond that, the entire RSS feed mechanism would
be much better in XMPP as pubsub. Twitter API and clients are the
worst of all. While RSS clients poll every hour, Twitter clients
HTTP-poll every minute.

To put it in other words: XMPP style two way messaging can emulate
HTTP style request/response easily. But HTTP has a hard time to
emulate two way messaging or notifications.

Would be interesting to put an XMPP transport under a Web browser and
let the XMPP server do the HTTP gateway until content servers support
XMPP natively.

Won't be easy to replace the entire infrastructure, though :-)

So, to answer your question: You might concentrate on gatewaying. Then
you can use much of the existing infrastructure. E.g. by building a
XMPP-WEBDAV gateway. WEBDAV servers provide all document management
you need for Web sites. Only thing missing to use it from the XMPP
client is a gateway. The gateway as a XMPP server component would
translate WEBDAV requests in XMPP-get/set to HTTP. Basically a
WEBDAV/XMPP to WEBDAV/HTTP gateway. What do you think?

Best
hw

On Mon, Mar 23, 2009 at 1:25 AM, Xavier Maillard <xma at gnu.org> wrote:
> Hi,
>
> I am writting a text editor with the aim to publish
> notes/articles/whatever over XMPP. I have all the basic editor
> stuff working and now has come the time to choose how to
> effectively "publish" these texts.
>
> My goal behind this, is to have access to my notes anywhere at
> anytime. I am not sure what the best method I should choose to
> store all this stuff. I know there were tries to have webdav over
> XMPP, I know there is pubsub (which has my preference) ?and
> lately I felt upon something called "jabdisk". I am looking for
> information about the later.
>
> OTOH, if you have any idea on a global storage strategy for my
> client, feel free to share them :)
>
> My main interest in writing this software is to be able to run a
> "jabber site" (aka a website) totally via XMPP and particulary a
> "XMPP wiki".
>
> Regards,
>
> ? ? ? ?Xavier
> --
> http://www.gnu.org
> http://www.april.org
> http://www.lolica.org
> _______________________________________________
> JDev mailing list
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________
>



-- 
Dr. Heiner Wolf
wolf.heiner at gmail.com
www.wolfspelz.de
www.virtual-presence.org

From simon at buddycloud.com  Fri Apr 10 08:11:11 2009
From: simon at buddycloud.com (Simon Tennant)
Date: Fri, 10 Apr 2009 15:11:11 +0200
Subject: [jdev] Using XMPP to talk to a mobile client
In-Reply-To: <grlc0r$nl9$1@ger.gmane.org>
References: <907698.28410.qm@web95414.mail.in2.yahoo.com>
	<grlc0r$nl9$1@ger.gmane.org>
Message-ID: <49DF456F.3080400@buddycloud.com>

Mobile is tricky: you fire off a stanza just as you enter a tunnel with
no coverage and your client is none the wiser as to whether the stanza
actually made it to the server. Indeed your GPRS or 3G connection may
even stay connected.

We have also had good success on the mobile by using sockets rather than
BOSH in the Buddycloud client. 

There are a couple of tricks that we used to ensure we loose no messages:

    * On mobile networks the phone client may be pushing off messages
      into a socket that has lost cellular coverage.  If you have a
      large sliding window on the TCP layer, these messages are lost.
      Twiddling your TCP stack can help keep the number of packets
      between ACKs low.
    * We have worked around these by using message archiving (XEP-0136)
      and re-requesting messages slightly before the device lost connection.
    * "warm starting".  In a bouncy environment having to pull down the
      roster, PEP and pub-sub subscriptions each time will get
      expensive.  If a session can be recovered, recover, and keep on going.

The real solution will be implementing XEP-0198: Stream Management and
managing acknowledged stanzas at the application layer. This is
something that we plan on implementing to handle the unpredictable
mobile environment.

S.

Alexander Gnauck wrote:
> Mridul Muralidharan wrote:
>   
>> Just to mention, BOSH does not have any same client IP requirement/restriction.
>>
>> And unlike tcp binding of xmpp - where session is terminated if disconnected, BOSH does handle disconnects in its design.
>>
>> The only requirements would be -
>>
>> a) ability of the client to connect back before the session/idle timeout.
>> b) BOSH gateway not going down.
>> c) BOSH client not going down.
>>
>> b and c are mentioned - so that the session state (rid, etc) is not lost.
>>     
>
> I have a much better experience with sockets on Mobile devices than with 
> BOSH. Of course this also depends how reliable you Mobile network is, 
> but in Europe its very good, and sockets works very well.
>
> Regards,
> Alex
> --
> Alexander Gnauck
> http://www.ag-software.de
> xmpp:gnauck at jabber.org
>
> _______________________________________________
> JDev mailing list
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________
>
>
>   


-- 
Simon Tennant
Buddycloud
uk: +44 20 7043 6756               de: +49 89 420 955 854  
uk: +44 78 5335 6047               de: +49 17 8545 0880
email and xmpp: simon at buddycloud.com
http://buddycloud.com


From whateley at gmail.com  Fri Apr 10 10:49:25 2009
From: whateley at gmail.com (Brendan Taylor)
Date: Fri, 10 Apr 2009 09:49:25 -0600
Subject: [jdev] jabber disk ?
In-Reply-To: <200903222325.n2MNPGCE017257@zogzog.maillard.mobi>
References: <200903222325.n2MNPGCE017257@zogzog.maillard.mobi>
Message-ID: <20090410154925.GB23928@nyarlathotep>

On Mon, Mar 23, 2009 at 12:25:16AM +0100, Xavier Maillard wrote:
> OTOH, if you have any idea on a global storage strategy for my
> client, feel free to share them :)
> 
> My main interest in writing this software is to be able to run a
> "jabber site" (aka a website) totally via XMPP and particulary a
> "XMPP wiki".

It seems to me that for this kind of project it would make sense to base
your protocol on the Atom Publishing Protocol. That gives you a pretty
well-supported representation for your pages, and as Heiner said it would
be pretty easy to imitate the HTTP requests in XMPP. It would be
interesting to see what aspects of AtomPub could be done differently
when XMPP is being used instead of HTTP.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://mail.jabber.org/pipermail/jdev/attachments/20090410/d459e71c/attachment.pgp 

From elghinn at free.fr  Fri Apr 10 14:47:25 2009
From: elghinn at free.fr (=?UTF-8?B?QW5hw6tsIFZlcnJpZXI=?=)
Date: Fri, 10 Apr 2009 21:47:25 +0200
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <5b698f5a0904100246t3a8f569dja688cb2f88f4d7a8@mail.gmail.com>
References: <49DED3A2.1030608@free.fr>
	<5b698f5a0904100246t3a8f569dja688cb2f88f4d7a8@mail.gmail.com>
Message-ID: <49DFA24D.8060707@free.fr>

Norman Rasmussen a ?crit :
> On Fri, Apr 10, 2009 at 7:05 AM, Ana?l Verrier <elghinn at free.fr> wrote:
> 
>> Why a fork? Because xmpppy was almost dead in the last 2 years. Because
>> there
>> are so many things which do not suit me (like the lack of PEP 8-compliance,
>> the
>> lack of file transfer support, the coding style, the hierarchy of the code,
>> the
>> "plugin" system, the simulation of heritage, etc.).
>>
> 
> As one of the co-maintainers of xmpp.py, why is this the first time i've
> heard of this? Alexey has recently contacted me to say that he's got time
> to work on xmpp.py fixing bugs, etc, and was due to release 0.5rc1 soon.

1) I have submited a patch[1] 11 months ago.
But my patch was waiting without responses. It was not alone[2][3][4][5].

2) No clues the project was alive.
See 1).
There was only few commits in the last year, and even less if we don't count 
those which do not touch with the code (like [6] and [7])

3) We didn?t announce anything before we had something to announce.
I do not have as a practice to announce a project prematurely.

4) Misfortunate timing.
I have forked the 03/26/09 as you can see on the project timeline[8]. And 
released it today. When I have forked, Alexey had not improved yet with the 
code. Thus I had already made things before he is not put at it.

Yes, when I make the release, that made already 4-5 days that there had been of 
the activity on the repository. But I only saw it when the release was done.

But does that really change something?

5) Gr?goire Menuel proposed a patch[9] for the file transfer.
But you refused it. And whatever is the reason, at the current hour we can not 
still make a file transfer with xmpppy.

I find important to have the file transfer, in particular for a bot.

For example, Erwan Briand, the author of CodingTeam[10] and administrator of 
codingteam.net, envisages to make a robot by which one will be able to download 
the versions of the projects directly since jabber without having to go on the 
site. And it is only one example among so many others.

[1] 
http://sourceforge.net/tracker/?func=detail&aid=1961193&group_id=97081&atid=616917
[2] 
http://sourceforge.net/tracker/?func=detail&aid=1962375&group_id=97081&atid=616917
[3]
http://sourceforge.net/tracker/?func=detail&aid=1780774&group_id=97081&atid=616917
[4]
http://sourceforge.net/tracker/?func=detail&aid=1929415&group_id=97081&atid=616915
[5]
http://sourceforge.net/tracker/?func=detail&aid=1949483&group_id=97081&atid=616915

[6] 
http://xmpppy.cvs.sourceforge.net/viewvc/xmpppy/xmpppy/xmpp/protocol.py?r1=1.58&r2=1.59
[7] 
http://xmpppy.cvs.sourceforge.net/viewvc/xmpppy/xmpppy/xmpp/protocol.py?r1=1.57&r2=1.58

[8] http://trac.last-exile.org/xmppony/changeset/1

[9]
http://sourceforge.net/mailarchive/forum.php?thread_name=1122740972.42ebaaec4a799%40webmail.insa-lyon.fr&forum_name=xmpppy-devel

[10] http://codingteam.codingteam.net/


> 
> I have not yet reviewed the differences, but would you be interested in
> feeding back your changes to xmpp.py?
> 

Our fixes are and will be free software, you?ll be able to take them back if you 
want. However, I have the intention to change quite a lot of things: revamp 
simplexmp, replace debug with standard logging, get rid of fake inheritance, 
etc. Are these ground-breaking changes suitable for incorporation in xmpppy?



--
Ana?l Verrier
xmpp:elghinn at last-exile.org
GPG: 1024D/65B95D84


From norman at rasmussen.co.za  Fri Apr 10 16:23:52 2009
From: norman at rasmussen.co.za (Norman Rasmussen)
Date: Fri, 10 Apr 2009 23:23:52 +0200
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <49DFA24D.8060707@free.fr>
References: <49DED3A2.1030608@free.fr>
	<5b698f5a0904100246t3a8f569dja688cb2f88f4d7a8@mail.gmail.com>
	<49DFA24D.8060707@free.fr>
Message-ID: <5b698f5a0904101423k50f9f500m57ca90888cd76423@mail.gmail.com>

On Fri, Apr 10, 2009 at 9:47 PM, Ana?l Verrier <elghinn at free.fr> wrote:
> 1) I have submited a patch[1] 11 months ago.
> But my patch was waiting without responses. It was not alone[2][3][4][5].

Unfortunately I haven't been looking at the bug tracker on sf.net, I
haven't had time to more than apply patches sent to the mailing list.

> 2) No clues the project was alive.

the xmpp.py mailing list has about 5 or so threads per month, of which
I read each and every message.  If this thread gets anymore detailed,
I think we should perhaps redirect it to that list so that we don't
overwhelm the jdev list with our plans to rule python-xmpp
development.

> 3) We didn?t announce anything before we had something to announce.
> I do not have as a practice to announce a project prematurely.

sounds good

> 4) Misfortunate timing.
> I have forked the 03/26/09 as you can see on the project timeline[8]. And
> released it today. When I have forked, Alexey had not improved yet with the
> code. Thus I had already made things before he is not put at it.
> Yes, when I make the release, that made already 4-5 days that there had been of
> the activity on the repository. But I only saw it when the release was done.

true, misfortunate timing, yes.

> 5) Gr?goire Menuel proposed a patch[9] for the file transfer.
> But you refused it. And whatever is the reason, at the current hour we can not
> still make a file transfer with xmpppy.

wow, this was from before I started on xmpp.py.  Do you know that
there were no less than 3 requests for file transfer code in the last
6 months.  If I'd known I would have at least looked at the patch.

> Our fixes are and will be free software, you?ll be able to take them back if you
> want. However, I have the intention to change quite a lot of things: revamp
> simplexmp, replace debug with standard logging, get rid of fake inheritance,
> etc. Are these ground-breaking changes suitable for incorporation in xmpppy?

as far as I'm concerned:
 - simplexml is ugly and should be thrown away.  something like the
standard python xml.dom and xml.sax (maybe xml.dom.pulldom) would be
more than enough
 - agree on the debugging
 - not sure what you mean about the fake inheritance - do you mean the
plugging?

Much of the code of xmpp.py was written by Alexey _before_ python had
support for all this stuff in it's internal libraries.  I've had to
deal with being able to run the transports on Python 2.2.  I think
Alexey did a fantastic job with what he had to work with when he wrote
the library.  Unfortunately (as it happens to all of us), he was
unable to dedicate as much time as he would have wanted to maintaining
the library.

Moving forwards I would like to see:
 - true asynchronous code - Gajim team did this about a year ago.
They added non-blocking calls for almost everything that used to
block.  Support for asyncore would be great, because this is another
python built-in library.
 - cleaner separation of concerns - the Gajim team have started on
this.  The client should not care if the server connection is TCP or
TLS or SSL or BOSH or Magic-transport-method-5.
 - the library should continue to support client and transport
connections.  adhoc commands should get client-side (consumer) support
(currently only server-side (producer) is supported).
 - file transfer would be fantastic, would you support all 5 methods?
(si, ibb, oob, socks5, jingle)

-- 
- Norman Rasmussen
 - Email: norman at rasmussen.co.za
 - Home page: http://norman.rasmussen.co.za/

From elghinn at free.fr  Fri Apr 10 16:48:09 2009
From: elghinn at free.fr (=?ISO-8859-15?Q?Ana=EBl_Verrier?=)
Date: Fri, 10 Apr 2009 23:48:09 +0200
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <1239363048.5108.6.camel@localhost.localdomain>
References: <49DED3A2.1030608@free.fr>
	<1239363048.5108.6.camel@localhost.localdomain>
Message-ID: <49DFBE99.3090103@free.fr>

Stephan Erb a ?crit :
> Hey,
> 
> Gajim has forked xmpppy as well. I guess the main difference is a switch
> to non-blocking sockets and the implementation of BOSH.
> 
> Maybe there is a chance here to streamline all those different efforts.
> 
> Best,
> steve-e
> 
> 
Gajim uses non-blocking sockets to not have to use threads. I do not think only 
it is necessary to neglect the use of threads just to not have to be bored with, 
especially at the hour of the processors multi-cores.

Moreover as Yann said, the fork of Gajim does not really have anything any more 
to do with the xmpppy origin. So to reinstate my work in the fork of Gajim is 
impossible (of as much more than I do not intend to pass by non-blocking sockets).

Of elsewhere, it seems that the fork of Gajim is integrated now too much into 
Gajim, as if that had always done only one with Gajim.

So, that would involve large change in Gajim to set out again on the use of a 
third library.

To finish, I would say that I really intend to go in another direction that is 
currently taken by xmpppy. Although this release seems to bring nothing more 
than some corrections of bugs, a better respect of the pep8, and the file 
transfer, it is necessary to keep with the spirit that it is there to 
officialize the project.

As I said to Norman Rasmussen, I do not have any problem against the fact that 
it reinstates my modifications in xmpppy. But very sincerely I doubt that all my 
modifications are reinstated in xmpppy.

And although Alexey very recently recovered above, what says to us that he will 
have time to leave the 0.5 and to continue thereafter? Who says to us that there 
will not be another 2 year hole in the development of xmpppy?

I do not seek to blame him. He has his life. And I thank him for the work which 
he already carried out until now. Only for the reasons already evoked, I felt 
the need to fork xmpppy.

Future will tell whether my project is a mere waste of time or whether it really 
has its place. While keeping in mind that I have nothing against a future 
bringing together of the two projects, here and now I prefer coding and going ahead.

--
Ana?l Verrier
xmpp:elghinn at last-exile.org
GPG: 1024D/65B95D84

From xma at gnu.org  Sat Apr 11 13:25:02 2009
From: xma at gnu.org (Xavier Maillard)
Date: Sat, 11 Apr 2009 20:25:02 +0200
Subject: [jdev] jabber disk ?
In-Reply-To: message from Peter Saint-Andre on Mon, 06 Apr 2009 22:20:45 -0600
Message-ID: <200904111825.n3BIP2X7015823@zogzog.maillard.mobi>

Hi,

   On 3/22/09 5:25 PM, Xavier Maillard wrote:
   > 
   > I am writting a text editor with the aim to publish
   > notes/articles/whatever over XMPP. I have all the basic editor
   > stuff working and now has come the time to choose how to
   > effectively "publish" these texts.
   > 
   > My goal behind this, is to have access to my notes anywhere at
   > anytime. I am not sure what the best method I should choose to
   > store all this stuff. I know there were tries to have webdav over
   > XMPP, I know there is pubsub (which has my preference)  and
   > lately I felt upon something called "jabdisk". I am looking for
   > information about the later.
   > 
   > OTOH, if you have any idea on a global storage strategy for my
   > client, feel free to share them :)
   > 
   > My main interest in writing this software is to be able to run a
   > "jabber site" (aka a website) totally via XMPP and particulary a
   > "XMPP wiki".

   Why? Isn't that what HTTP is for?

Why ?

Some reasons:

1. for fun
2. to just have something cool to demo at my next LUG meeting
3. I am more likely to use XMPP services than any other service
(I am even connected 24/7 with my jid via my mobile)
4. I'd like to test/implement XEPs in real life

Enough ?

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

From jonathan.dickinson at k2.com  Tue Apr 14 07:08:06 2009
From: jonathan.dickinson at k2.com (Jonathan Dickinson)
Date: Tue, 14 Apr 2009 14:08:06 +0200
Subject: [jdev] Digest URIs for XMPP
Message-ID: <A790BE8D83ECC3469047C2E344EABE61027C685F7D52@zamail01.k2workflow.com>

I am busy doing the SASL lib for my server/client (almost completely finished with DIGEST-MD5). I was just wondering what the common practice is for digest-uris with varying ports. Some people use them as follows:

Port 80:
http/www.foo.com
Port 8080:
http/www.foo.com

Where others:

Port 80:
http/www.foo.com
Port 8080:
http/www.foo.com:8080

So which one is in common use in the XMPP world?

Also where the connect server is different I would assume the following would apply (I am just confirming what I have read):

xmpp/talk.google.com/google.com

Or even:

xmpp/talk.google.com/gmail.com

Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/jdev/attachments/20090414/46e71d6a/attachment.htm 

From stpeter at stpeter.im  Tue Apr 14 11:19:21 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 14 Apr 2009 10:19:21 -0600
Subject: [jdev] Digest URIs for XMPP
In-Reply-To: <A790BE8D83ECC3469047C2E344EABE61027C685F7D52@zamail01.k2workflow.com>
References: <A790BE8D83ECC3469047C2E344EABE61027C685F7D52@zamail01.k2workflow.com>
Message-ID: <49E4B789.40800@stpeter.im>

On 4/14/09 6:08 AM, Jonathan Dickinson wrote:
> I am busy doing the SASL lib for my server/client (almost completely
> finished with DIGEST-MD5). I was just wondering what the common practice
> is for digest-uris with varying ports. Some people use them as follows:
> 
>  
> 
> Port 80:
> 
> http/www.foo.com
> 
> Port 8080:
> 
> http/www.foo.com
> 
>  
> 
> Where others:
> 
>  
> 
> Port 80:
> 
> http/www.foo.com
> 
> Port 8080:
> 
> http/www.foo.com:8080
> 
>  
> 
> So which one is in common use in the XMPP world?

Isn't this what SRV records are for?

> Also where the connect server is different I would assume the following
> would apply (I am just confirming what I have read):
> 
>  
> 
> xmpp/talk.google.com/google.com
> 
>  
> 
> Or even:
> 
>  
> 
> xmpp/talk.google.com/gmail.com

As you know from RFC 2831, the format is:

serv-type "/" host [ "/" serv-name ]

The serv-type is always xmpp for us.

The host is the machine you connect to (or discover via SRV).

The serv-name is the name used by the client to discover the machine.

In the case of Google Talk, you look up gmail.com (or googlemail.com or
whatever) and discover things like this:

$ dig +short -t SRV _xmpp-client._tcp.gmail.com
20 0 5222 talk4.l.google.com.
5 0 5222 talk.l.google.com.
20 0 5222 talk1.l.google.com.
20 0 5222 talk2.l.google.com.
20 0 5222 talk3.l.google.com.

So I think that the resulting digest-uri would be of this form:

xmpp/talk.l.google.com/gmail.com

But I freely admit that this might be subject to interpretation, as so
many things are when it comes to the DIGEST-MD5 SASL mechanism. :(

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/jdev/attachments/20090414/8a53d1c3/attachment.bin 

From stpeter at stpeter.im  Tue Apr 14 17:09:55 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 14 Apr 2009 16:09:55 -0600
Subject: [jdev] MXM #2
Message-ID: <49E509B3.2090308@stpeter.im>

On March 12 and again today, we held a "Monthly XMPP Meeting":

http://logs.jabber.org/jdev at conference.jabber.org/2009-03-12.html#15:01:15

http://logs.jabber.org/jdev at conference.jabber.org/2009-04-14.html#14:06:45

I know it's a bit backwards, but I'm going to report on today's meeting
first because it's fresh in my mind (and sorry about not yet publishing
minutes from the first meeting). There was no set agenda, but we talked
about the following topics:

1. Last Call for XEP-0232 (Software Information)

http://xmpp.org/extensions/xep-0232.html

http://logs.jabber.org/jdev at conference.jabber.org/2009-04-14.html#14:10:41

Points:

- Is this a misuse of service discovery?

- Will this make entity capability caches less useful because they will
be too large to search easily?

- Does it make more sense to publish this information via PEP using the
XEP-0092 format?

The XMPP Council will vote on XEP-0232 at its next meeting (April 22).
More feedback is welcome before then.

2. Last Call for XEP-0237 (Roster Versioning)

http://xmpp.org/extensions/xep-0237.html

http://logs.jabber.org/jdev at conference.jabber.org/2009-04-14.html#14:23:19

General agreement that this is in good shape. There are still a few edge
cases to figure out, especially the empty roster case.

3. Last Calls for the core Jingle specs

http://logs.jabber.org/jdev at conference.jabber.org/2009-04-14.html#14:29:52

No real discussion here. Most people seemed to think that these are
ready for Draft.

4. Pubsub/PEP implementations

http://logs.jabber.org/jdev at conference.jabber.org/2009-04-14.html#14:37:41

Consensus that we need more interop testing among idavoll, ejabberd,
Openfire, Tigase, etc. Perhaps make this a focus at the next XMPP Summit.

5. XEP-0198 (Stream Management)

http://xmpp.org/extensions/xep-0198.html

http://logs.jabber.org/jdev at conference.jabber.org/2009-04-14.html#14:53:43

People like this. Let's go forth and implement. :)

6. Bidirectional s2s

http://logs.jabber.org/jdev at conference.jabber.org/2009-04-14.html#15:00:34

We decided that we need a dedicated discussion session about s2s fixes
and improvements (dialback, multiplexing domains over a given stream via
TLS/SASL/dialback/whatever, etc.). We agreed to make that the focus of
the next Monthly XMPP Meeting, tentatively scheduled for May 5.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/jdev/attachments/20090414/696ff0c2/attachment.bin 

From Kurt.Zeilenga at Isode.com  Tue Apr 14 22:30:36 2009
From: Kurt.Zeilenga at Isode.com (Kurt Zeilenga)
Date: Tue, 14 Apr 2009 20:30:36 -0700
Subject: [jdev] Digest URIs for XMPP
In-Reply-To: <49E4B789.40800@stpeter.im>
References: <A790BE8D83ECC3469047C2E344EABE61027C685F7D52@zamail01.k2workflow.com>
	<49E4B789.40800@stpeter.im>
Message-ID: <452495EA-3CB7-40BD-A773-B4B144397FC9@Isode.com>

I think clients ought to simply assert xmpp/host where host is  
whatever string the user specified to connect to.

But more importantly is what should the server do.  RFC 2831 says:
    Servers SHOULD check that the supplied value is correct. This will
    detect accidental connection to the incorrect server. It is also so
    that clients will be trained to provide values that will work with
    implementations that use a shared back-end authentication service
    that can provide server authentication.

I suggest instead:
    Servers SHOULD ignore that the supplied value.  The check
    was intended to detect that client did not accidentally
    connect to the incorrect server.  Performing the check will far more
    likely lead to disconnecting of clients which did connect to the
    correct server than disconnecting clients which accidentally  
connected
    to an incorrect server.

Such checks tend to make the application services brittle.   (Consider  
the implications of forward and reverse NAT devices, transparent (to  
the client and server) tunneling, etc.)

-- Kurt


From dave at cridland.net  Wed Apr 15 04:54:49 2009
From: dave at cridland.net (Dave Cridland)
Date: Wed, 15 Apr 2009 10:54:49 +0100
Subject: [jdev] [Standards] MXM #2
In-Reply-To: <49E509B3.2090308@stpeter.im>
References: <49E509B3.2090308@stpeter.im>
Message-ID: <7088.1239789289.390264@puncture>

On Tue Apr 14 23:09:55 2009, Peter Saint-Andre wrote:
> The XMPP Council will vote on XEP-0232 at its next meeting (April  
> 22).
> More feedback is welcome before then.
> 
> 
As usual, you're welcome to turn up to the Council meetings, and  
express your views there. (But for the next meeting, you'll need to  
bring cake.)

> We decided that we need a dedicated discussion session about s2s  
> fixes
> and improvements (dialback, multiplexing domains over a given  
> stream via
> TLS/SASL/dialback/whatever, etc.). We agreed to make that the focus  
> of
> the next Monthly XMPP Meeting, tentatively scheduled for May 5.

Matthew Wild and I have agreed to write "something" up in terms of a  
strawman proposal we can batter about.

Feel free to write one too - I'll endeavour to send something to the  
list before then.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From jonathan.dickinson at k2.com  Wed Apr 15 07:52:13 2009
From: jonathan.dickinson at k2.com (Jonathan Dickinson)
Date: Wed, 15 Apr 2009 14:52:13 +0200
Subject: [jdev] SASL (again)
Message-ID: <A790BE8D83ECC3469047C2E344EABE61027CE3C683B4@zamail01.k2workflow.com>

Hi All,

RFC 4616 implies that it is possible to store a digest for CRAM-MD5 in the database (just above 3. Pseudo-Code). From what I can tell you need to store a plain-text password (at best the XORed passwords, which is pointless).

A CRAM digest is created as follows:

MD5(
   (K XOR opad),
   MD5(
      (K XOR ipad),
      timestamp
      )
   )

Where 'timestamp' is variant ("<" num "." num "@" domain ">"). Am I missing some mathematical nuance, or is RFC 4616 misleading?

Jonathan




From dave at cridland.net  Wed Apr 15 09:57:53 2009
From: dave at cridland.net (Dave Cridland)
Date: Wed, 15 Apr 2009 15:57:53 +0100
Subject: [jdev] SASL (again)
In-Reply-To: <A790BE8D83ECC3469047C2E344EABE61027CE3C683B4@zamail01.k2workflow.com>
References: <A790BE8D83ECC3469047C2E344EABE61027CE3C683B4@zamail01.k2workflow.com>
Message-ID: <7088.1239807473.358000@puncture>

On Wed Apr 15 13:52:13 2009, Jonathan Dickinson wrote:
> Hi All,
> 
> RFC 4616 implies that it is possible to store a digest for CRAM-MD5  
> in the database (just above 3. Pseudo-Code). From what I can tell  
> you need to store a plain-text password (at best the XORed  
> passwords, which is pointless).
> 
> 
In all practical senses, yes, but it's possible to store a  
digest-like entity.

> A CRAM digest is created as follows:
> 
> MD5(
>    (K XOR opad),
>    MD5(
>       (K XOR ipad),
>       timestamp
>       )
>    )

Where, in turn, K is derived from, in C-like pseudocode:

K = (strlen(password) > L) ? MD5(password) : password + ('\0' * (L -  
strlen(password)))
Where L is the block length of the hash algorithm, or 128 bits in the  
case of MD5.

So K might be reasonable stuff, or it might be the password.

But that's not what CRAM-MD5 suggests storing - they suggest storing  
the intemediate hash states - effectively an MD5 internal array pair  
pre-primed with (K ^ opad) and (K ^ ipad). This is considerably more  
secure than "just a XOR", as K is at least one block-size, and  
therefore it's roughly the same, I think, as an MD5 to extract the  
password, which is to say it requires a brute-force attack, made  
harder because the combination of the two hashes means that you need  
to find a solution to both.

Still, in general, you just call an HMAC-MD5 function in some  
library, and, in rare cases, you write the HMAC wrapper over a stock  
MD5 - either way, the best you have is the XOR products, which aren't  
nearly as good unless your users really like long passwords.

Moreover, by doing this, you're forced into storing a seperate secret  
for DIGEST-MD5, so in most cases, server implementors have two modes  
- storing plaintext passwords, for flexiblility in mechanisms, and  
storing hashed passwords, which essentially restricts to PLAIN and -  
hopefully soon - SCRAM.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From elghinn at free.fr  Wed Apr 15 19:08:18 2009
From: elghinn at free.fr (=?UTF-8?B?QW5hw6tsIFZlcnJpZXI=?=)
Date: Thu, 16 Apr 2009 02:08:18 +0200
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <5b698f5a0904101423k50f9f500m57ca90888cd76423@mail.gmail.com>
References: <49DED3A2.1030608@free.fr>	<5b698f5a0904100246t3a8f569dja688cb2f88f4d7a8@mail.gmail.com>	<49DFA24D.8060707@free.fr>
	<5b698f5a0904101423k50f9f500m57ca90888cd76423@mail.gmail.com>
Message-ID: <49E676F2.3030804@free.fr>

Norman Rasmussen a ?crit :
>> Our fixes are and will be free software, you?ll be able to take them back if you
>> want. However, I have the intention to change quite a lot of things: revamp
>> simplexmp, replace debug with standard logging, get rid of fake inheritance,
>> etc. Are these ground-breaking changes suitable for incorporation in xmpppy?
> 
> as far as I'm concerned:
>  - simplexml is ugly and should be thrown away.  something like the
> standard python xml.dom and xml.sax (maybe xml.dom.pulldom) would be
> more than enough
I don't think that removing simplexml would be a good thing. simplexml is simple
(Captain Obvious agrees), and having a simple API to make Python objets from an
XML stream (thanks to expat) and serialize them back (thanks to __str__) seems
useful to me. I prefer cleaning simplexml than using DOM. I think we don?t need
such a complicated interface to handle stanzas.

>  - not sure what you mean about the fake inheritance - do you mean the
> plugging?
Yes, the plugin system and the horror[1] in client.py (CommonClient is derivated
in Client and Component, but its contructor does different things according to
the one call it (Client.__init__ or Component.__init__)). And other stuff like
this one.

[1] http://trac.last-exile.org/xmppony/browser/trunk/xmppony/client.py?rev=30#L119

> 
> Much of the code of xmpp.py was written by Alexey _before_ python had
> support for all this stuff in it's internal libraries.  I've had to
> deal with being able to run the transports on Python 2.2.  I think
> Alexey did a fantastic job with what he had to work with when he wrote
> the library.  Unfortunately (as it happens to all of us), he was
> unable to dedicate as much time as he would have wanted to maintaining
> the library.
> 
As I already said to steve-e, I thank him for his job and I don't blame him: he
has his life.

> Moving forwards I would like to see:
>  - true asynchronous code - Gajim team did this about a year ago.
> They added non-blocking calls for almost everything that used to
> block.  Support for asyncore would be great, because this is another
> python built-in library.
I don't understand why people do not like threads :'(
threading is a standard Python module too.

>  - cleaner separation of concerns - the Gajim team have started on
> this.  The client should not care if the server connection is TCP or
> TLS or SSL or BOSH or Magic-transport-method-5.
That sounds good.

I want Magic-transport-method-5 \o/

>  - the library should continue to support client and transport
> connections.  adhoc commands should get client-side (consumer) support
> (currently only server-side (producer) is supported).
Adhoc commands, pep, and other cool stuff are on my roadmap for v0.3.


>  - file transfer would be fantastic, would you support all 5 methods?
> (si, ibb, oob, socks5, jingle)
> 
For now, xmppony supports si, socks5 and ibb. With emacs-jabber, I can already
send and receive files from a bot based on xmppony.
Jingle support would be great, but I didn't plan to touch it now (except if
someone sends me a patch).


As I said in previous mail, for v0.2, I plan to revamp simplexml, replace debug
with standard logging and get rid of fake inheritance. But I also take a look to
rfcs and xeps. Because they evolved since the code was written. For example, I
found 2 problems in omega's patch (which was written 4-5 years ago). I also plan
to make some unit tests.

The base must be cleanest possible before going further!


-- 
Ana?l Verrier
xmpp:elghinn at last-exile.org
GPG: 1024D/65B95D84




From asterix at lagaule.org  Thu Apr 16 02:21:32 2009
From: asterix at lagaule.org (Yann Leboulanger)
Date: Thu, 16 Apr 2009 09:21:32 +0200
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <49E676F2.3030804@free.fr>
References: <49DED3A2.1030608@free.fr>	<5b698f5a0904100246t3a8f569dja688cb2f88f4d7a8@mail.gmail.com>	<49DFA24D.8060707@free.fr>	<5b698f5a0904101423k50f9f500m57ca90888cd76423@mail.gmail.com>
	<49E676F2.3030804@free.fr>
Message-ID: <49E6DC7C.6080209@lagaule.org>

Ana?l Verrier wrote:

> As I said in previous mail, for v0.2, I plan to revamp simplexml, replace debug
> with standard logging and get rid of fake inheritance. But I also take a look to
> rfcs and xeps. Because they evolved since the code was written. For example, I
> found 2 problems in omega's patch (which was written 4-5 years ago). I also plan
> to make some unit tests.

We already have logging system based on logging module in Gajim
We have unittest for some xmpppy things. Have a look at test folder.
What about zeroconf?

Really sad all that work is duplicated :/

-- 
Yann

From norman at rasmussen.co.za  Thu Apr 16 03:12:34 2009
From: norman at rasmussen.co.za (Norman Rasmussen)
Date: Thu, 16 Apr 2009 10:12:34 +0200
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <49E676F2.3030804@free.fr>
References: <49DED3A2.1030608@free.fr>
	<5b698f5a0904100246t3a8f569dja688cb2f88f4d7a8@mail.gmail.com>
	<49DFA24D.8060707@free.fr>
	<5b698f5a0904101423k50f9f500m57ca90888cd76423@mail.gmail.com>
	<49E676F2.3030804@free.fr>
Message-ID: <5b698f5a0904160112k76801109k50c6d7f7e2394c41@mail.gmail.com>

On Thu, Apr 16, 2009 at 2:08 AM, Ana?l Verrier <elghinn at free.fr> wrote:
>> ?- true asynchronous code - Gajim team did this about a year ago.
>> They added non-blocking calls for almost everything that used to
>> block. ?Support for asyncore would be great, because this is another
>> python built-in library.
> I don't understand why people do not like threads :'(
> threading is a standard Python module too.

because you can't spin off one thread for each connection on a server :-)

(on a client it's reasonable, because you may only have 5 to 10
threads, but one a server with 100+ threads, it starts to go haywire)

-- 
- Norman Rasmussen
 - Email: norman at rasmussen.co.za
 - Home page: http://norman.rasmussen.co.za/

From dave at cridland.net  Thu Apr 16 03:43:38 2009
From: dave at cridland.net (Dave Cridland)
Date: Thu, 16 Apr 2009 09:43:38 +0100
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <49DFBE99.3090103@free.fr>
References: <49DED3A2.1030608@free.fr>
	<1239363048.5108.6.camel@localhost.localdomain>
	<49DFBE99.3090103@free.fr>
Message-ID: <12297.1239871418.665567@puncture>

On Fri Apr 10 22:48:09 2009, Ana?l Verrier wrote:
> Gajim uses non-blocking sockets to not have to use threads. I do  
> not think only
> it is necessary to neglect the use of threads just to not have to  
> be bored with,
> especially at the hour of the processors multi-cores.

I think you want to be careful about what you're implying, there.  
Gajim's architecture - using a single non-blocking thread - is  
perfectly fine, as you certainly don't want or need multithreading  
there.

You do need threads for high-volume systems, but you want them  
scaling by core, not by connection.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From dmeyer at tzi.de  Thu Apr 16 07:04:43 2009
From: dmeyer at tzi.de (Dirk Meyer)
Date: Thu, 16 Apr 2009 14:04:43 +0200
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <49E676F2.3030804@free.fr> (=?iso-8859-1?Q?=22Ana=EBl?=
	Verrier"'s message of "Thu\, 16 Apr 2009 02\:08\:18 +0200")
References: <49DED3A2.1030608@free.fr>
	<5b698f5a0904100246t3a8f569dja688cb2f88f4d7a8@mail.gmail.com>
	<49DFA24D.8060707@free.fr>
	<5b698f5a0904101423k50f9f500m57ca90888cd76423@mail.gmail.com>
	<49E676F2.3030804@free.fr>
Message-ID: <87skk8x0ro.fsf@phex.sachmittel.de>

Ana?l Verrier wrote:
> I don't understand why people do not like threads :'(

Because you get race conditions


From dave at cridland.net  Thu Apr 16 07:17:46 2009
From: dave at cridland.net (Dave Cridland)
Date: Thu, 16 Apr 2009 13:17:46 +0100
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <87skk8x0ro.fsf@phex.sachmittel.de>
References: <49DED3A2.1030608@free.fr>
	<5b698f5a0904100246t3a8f569dja688cb2f88f4d7a8@mail.gmail.com>
	<49DFA24D.8060707@free.fr>
	<5b698f5a0904101423k50f9f500m57ca90888cd76423@mail.gmail.com>
	<49E676F2.3030804@free.fr> <87skk8x0ro.fsf@phex.sachmittel.de>
Message-ID: <12297.1239884266.048964@puncture>

On Thu Apr 16 13:04:43 2009, Dirk Meyer wrote:
> Ana?l Verrier wrote:
> > I don't understand why people do not like threads :'(
> 
> Because you get race conditions
> 
> 
And if you're in a race, and you have a loose thread, it can get  
caught on a bush an unravel your whole jumper.

Sorry, realised I hadn't made any bad jokes on this list in ages,  
although that does look like a disturbingly good analogy.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From merwok at netwok.org  Thu Apr 16 21:29:15 2009
From: merwok at netwok.org (=?utf-8?Q? =C3=89ric=20Araujo =20)
Date: Fri, 17 Apr 2009 04:29:15 +0200
Subject: [jdev] xmppony 0.1 is released!
Message-ID: <54216.1239935355@netwok.org>

Hello jdev


Let me first introduce myself, as a newcomer on this list. I am a Python
programmer and Jabber enthusiast. I hang around on some of the same chatrooms
as elghinn. I?ve known of the fork project since its beginning, made some minor
patches, and found the name. Note that my understanding of XMPP is incomplete:
I?ve read user documentation and some presentations about the protocol, but not
the specifications, therefore I cannot debate stuff related to the protocol
itself, but I do have strong opinions about Python code and some requests about
the features and API of the library. I speak on my own behalf, with bits from
discussions with elghinn.


[Yann Leboulanger]
> We already have logging system based on logging module in Gajim
I wanted to do this part of the fork, so I?ll make sure to look at Gajim?s
solution first. Thanks.

> We have unittest for some xmpppy things. Have a look at test folder.
I?m sure elghinn will look at that, especially since Gajim is under GPLv3 too.

> What about zeroconf?
Depends on the aims of xmppony. If it should be the Python library for clients,
bots and scripts, it would be in. If it aims at being the Python library for
scripts and bots (elghinn?s original idea), that would be overkill. elghinn
won?t write zeroconf support, but patches will probably be accepted. Or perhaps
not, if there?s no long-term support with the patches.

> Really sad all that work is duplicated :/
Well, this discussion is a starting point for cooperation.


[Norman Rasmussen]
>> I don't understand why people do not like threads :'(
> because you can't spin off one thread for each connection on a server :-)
elghinn does not intend to use Python for a server, seeing there are really
good C/C++ libraries out there.


[Dirk Meyer]
>> I don't understand why people do not like threads :'(
> Because you get race conditions
We believe locks can prevent them.


[Dave Cridland]
>> Gajim uses non-blocking sockets to not have to use threads. I do not think
>> only it is necessary to neglect the use of threads just to not have to be
>> bored with, especially at the hour of the processors multi-cores.
> I think you want to be careful about what you're implying, there. Gajim's
> architecture - using a single non-blocking thread - is  perfectly fine, as
> you certainly don't want or need multithreading there.
>
> You do need threads for high-volume systems, but you want them scaling by
> core, not by connection.
I?m not well-versed enough in parallel processing to make an answer here.

And thank you for the joke :]


Cheers,

?ric Araujo


From stpeter at stpeter.im  Tue Apr 21 17:27:26 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 21 Apr 2009 16:27:26 -0600
Subject: [jdev] gaming@xmpp.org
Message-ID: <49EE484E.6050105@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've created a new list for discussions related to gaming applications
of XMPP technologies. Subscribe here:

http://mail.jabber.org/mailman/listinfo/gaming

mailto:gaming-subscribe at xmpp.org

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknuSE4ACgkQNL8k5A2w/vzovwCcCwZR92qZi5MgTFfJoDlslHVu
ZmgAnR0hMr8bH3hBL7LEZI3ShR/WzT3j
=9IxI
-----END PGP SIGNATURE-----

From bf_lists at brainlounge.de  Wed Apr 22 03:36:57 2009
From: bf_lists at brainlounge.de (Bernd Fondermann)
Date: Wed, 22 Apr 2009 10:36:57 +0200
Subject: [jdev] [ANN] Apache Vysper and GSoC project
Message-ID: <49EED729.9040507@brainlounge.de>

Hi,

Apache Vysper (pronounce 'whisper', source[1], docs[2]) is an
ASL-licensed[4] open source XMPP implementation in Java currently under
development at the Apache Software Foundation.

After some years at Apache Labs, Vysper is now a sub-project of Apache
MINA[3] and development will hopefully take up speed there.

Vysper has seen no release yet, is not ready for production, and docs
are still sparse.

Additionally, I'm happy to announce that we can welcome Michael Jakl as
a Google Summer of Code student this year. He will implement PubSub for
Vysper. So XMPP is not completely lost on SoC :-)

The ASF is an open community not very different in mindset from the XSF.
So everybody here is invited to use, participate and contribute to
Apache Vysper.

Thanks for listening,

  Bernd

XMPP: berndf at jabber.org
MAIL: berndf at apache.org

[1] http://svn.apache.org/repos/asf/mina/sandbox/vysper
[2] http://cwiki.apache.org/confluence/display/labs/vysper
[3] http://mina.apache.org
[4] http://svn.apache.org/repos/asf/mina/sandbox/vysper/LICENSE.txt




From sh at defuze.org  Wed Apr 22 05:40:02 2009
From: sh at defuze.org (Sylvain Hellegouarch)
Date: Wed, 22 Apr 2009 12:40:02 +0200
Subject: [jdev] [ANN] Apache Vysper and GSoC project
In-Reply-To: <49EED729.9040507@brainlounge.de>
References: <49EED729.9040507@brainlounge.de>
Message-ID: <49EEF402.3080604@defuze.org>

Bernd Fondermann a ?crit :
> Hi,
>
> Apache Vysper (pronounce 'whisper', source[1], docs[2]) is an
> ASL-licensed[4] open source XMPP implementation in Java currently under
> development at the Apache Software Foundation.
>
> After some years at Apache Labs, Vysper is now a sub-project of Apache
> MINA[3] and development will hopefully take up speed there.
>
> Vysper has seen no release yet, is not ready for production, and docs
> are still sparse.
>
> Additionally, I'm happy to announce that we can welcome Michael Jakl as
> a Google Summer of Code student this year. He will implement PubSub for
> Vysper. So XMPP is not completely lost on SoC :-)
>
> The ASF is an open community not very different in mindset from the XSF.
> So everybody here is invited to use, participate and contribute to
> Apache Vysper.
>
> Thanks for listening,
>
>   Bernd
>
> XMPP: berndf at jabber.org
> MAIL: berndf at apache.org
>
> [1] http://svn.apache.org/repos/asf/mina/sandbox/vysper
> [2] http://cwiki.apache.org/confluence/display/labs/vysper
> [3] http://mina.apache.org
> [4] http://svn.apache.org/repos/asf/mina/sandbox/vysper/LICENSE.txt
>
>   

Nice.

However, how many XMPP server written in Java do we need? Why not 
helping on Tigase for instance? I'm puzzled since XMPP servers are hard 
to write, we had OpenFire then Tigase now Vysper.

Anyhow, all the best for it :)

- Sylvain

From bf_lists at brainlounge.de  Wed Apr 22 06:12:28 2009
From: bf_lists at brainlounge.de (Bernd Fondermann)
Date: Wed, 22 Apr 2009 13:12:28 +0200
Subject: [jdev] [ANN] Apache Vysper and GSoC project
In-Reply-To: <49EEF402.3080604@defuze.org>
References: <49EED729.9040507@brainlounge.de> <49EEF402.3080604@defuze.org>
Message-ID: <49EEFB9C.7070402@brainlounge.de>

Sylvain Hellegouarch wrote:
> Bernd Fondermann a ?crit :
>> Hi,
>>
>> Apache Vysper (pronounce 'whisper', source[1], docs[2]) is an
>> ASL-licensed[4] open source XMPP implementation in Java currently under
>> development at the Apache Software Foundation.
>>
>> After some years at Apache Labs, Vysper is now a sub-project of Apache
>> MINA[3] and development will hopefully take up speed there.
>>
>> Vysper has seen no release yet, is not ready for production, and docs
>> are still sparse.
>>
>> Additionally, I'm happy to announce that we can welcome Michael Jakl as
>> a Google Summer of Code student this year. He will implement PubSub for
>> Vysper. So XMPP is not completely lost on SoC :-)
>>
>> The ASF is an open community not very different in mindset from the XSF.
>> So everybody here is invited to use, participate and contribute to
>> Apache Vysper.
>>
>> Thanks for listening,
>>
>>   Bernd
>>
>> XMPP: berndf at jabber.org
>> MAIL: berndf at apache.org
>>
>> [1] http://svn.apache.org/repos/asf/mina/sandbox/vysper
>> [2] http://cwiki.apache.org/confluence/display/labs/vysper
>> [3] http://mina.apache.org
>> [4] http://svn.apache.org/repos/asf/mina/sandbox/vysper/LICENSE.txt
>>
>>   
> 
> Nice.
> 
> However, how many XMPP server written in Java do we need? Why not
> helping on Tigase for instance? I'm puzzled since XMPP servers are hard
> to write, we had OpenFire then Tigase now Vysper.

Thanks for the question, it is very valid.
You are right, the XMPP server ecosystem is very diverse (in terms of
implementation language). Yet, most of the implementations are GPL'ed.

I prefer BSD/ASL-licensed software - not neccessarily as a user, but
when writing code. (The GPL is a very good and a strong license, and so
are BSD-type licenses. Every class has its weaknesses and strengths. I
have not the slightest interest in discussion superiority of any of
them.) It's intended providing a choice here for XMPP server users.
Implementation-wise we are still far away from being that choice.

You could still argue that I should have tried to persuaed some
implementation to move to ASL, but (if they'd had agreed) that would
have taken all the fun of writing a XMPP server from scratch.

> Anyhow, all the best for it :)

Thanks! :-)

  Bernd

From sh at defuze.org  Wed Apr 22 06:30:51 2009
From: sh at defuze.org (Sylvain Hellegouarch)
Date: Wed, 22 Apr 2009 13:30:51 +0200 (CEST)
Subject: [jdev] [ANN] Apache Vysper and GSoC project
In-Reply-To: <49EEFB9C.7070402@brainlounge.de>
References: <49EED729.9040507@brainlounge.de> <49EEF402.3080604@defuze.org>
	<49EEFB9C.7070402@brainlounge.de>
Message-ID: <53147.193.253.216.132.1240399851.squirrel@mail1.webfaction.com>


> I prefer BSD/ASL-licensed software - not neccessarily as a user, but
> when writing code. (The GPL is a very good and a strong license, and so
> are BSD-type licenses. Every class has its weaknesses and strengths. I
> have not the slightest interest in discussion superiority of any of
> them.) It's intended providing a choice here for XMPP server users.
> Implementation-wise we are still far away from being that choice.

That's a valid point and I share your views on the licensing subject.

>
> You could still argue that I should have tried to persuaed some
> implementation to move to ASL, but (if they'd had agreed) that would
> have taken all the fun of writing a XMPP server from scratch.

True. Like I wrote my own XMPP lib in Python when I could've tried to help
an existing one. Fun is the first motivational aspect of most OSS projects
:)

- Sylvain


-- 
Sylvain Hellegouarch
http://www.defuze.org

From jonathan.dickinson at k2.com  Thu Apr 23 04:02:22 2009
From: jonathan.dickinson at k2.com (Jonathan Dickinson)
Date: Thu, 23 Apr 2009 11:02:22 +0200
Subject: [jdev] [ANN] Apache Vysper and GSoC project
In-Reply-To: <49EEF402.3080604@defuze.org>
References: <49EED729.9040507@brainlounge.de> <49EEF402.3080604@defuze.org>
Message-ID: <A790BE8D83ECC3469047C2E344EABE61027E35F7C3D6@zamail01.k2workflow.com>

> -----Original Message-----
> From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] On
> Behalf Of Sylvain Hellegouarch
> Sent: 22 April 2009 12:40 PM
> To: Jabber/XMPP software development list
> Subject: Re: [jdev] [ANN] Apache Vysper and GSoC project
> 
> [...] I'm puzzled since XMPP servers are hard
> to write, we had OpenFire then Tigase now Vysper.
> 

Amen. However, writing an XMPP server is a pleasure at the same time! It will be interesting to see what they come up with (it will be pretty hard to follow in Tigase' steps).

> Anyhow, all the best for it :)
> 
> - Sylvain
> _______________________________________________
> JDev mailing list
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________

From will at netmindz.net  Wed Apr 29 15:11:06 2009
From: will at netmindz.net (Will Tatam)
Date: Wed, 29 Apr 2009 21:11:06 +0100
Subject: [jdev] Flash conference
Message-ID: <49F8B45A.3030200@netmindz.net>

Anyone recommend any pre-existing flash xmpp conference clients ? I'm 
looking at add a flash chatroom to a site

I know I could build by own using XIFF but as i've not done and flash in 
about 3 years a pre-existing one would be preferable

Will

From dave at cridland.net  Wed Apr 29 15:20:36 2009
From: dave at cridland.net (Dave Cridland)
Date: Wed, 29 Apr 2009 21:20:36 +0100
Subject: [jdev] Flash conference
In-Reply-To: <49F8B45A.3030200@netmindz.net>
References: <49F8B45A.3030200@netmindz.net>
Message-ID: <15169.1241036436.511912@puncture>

On Wed Apr 29 21:11:06 2009, Will Tatam wrote:
> Anyone recommend any pre-existing flash xmpp conference clients ?  
> I'm looking at add a flash chatroom to a site
> 
> I know I could build by own using XIFF but as i've not done and  
> flash in about 3 years a pre-existing one would be preferable

Why Flash? Will Speeqe not do?

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From nathanfritz at gmail.com  Wed Apr 29 16:22:22 2009
From: nathanfritz at gmail.com (Nathan Fritz)
Date: Wed, 29 Apr 2009 14:22:22 -0700
Subject: [jdev] Flash conference
In-Reply-To: <15169.1241036436.511912@puncture>
References: <49F8B45A.3030200@netmindz.net> <15169.1241036436.511912@puncture>
Message-ID: <182eea400904291422k3ebed760o597074fec6db1983@mail.gmail.com>

On Wed, Apr 29, 2009 at 1:20 PM, Dave Cridland <dave at cridland.net> wrote:

> On Wed Apr 29 21:11:06 2009, Will Tatam wrote:
>
>> Anyone recommend any pre-existing flash xmpp conference clients ? I'm
>> looking at add a flash chatroom to a site
>
>
>> I know I could build by own using XIFF but as i've not done and flash in
>> about 3 years a pre-existing one would be preferable
>>
>
My Flash lib includes a MUC example.  Seesmic-AS3-XMPP aka TwhiX.


>
> Why Flash? Will Speeqe not do?
>
> Dave.
> --
> Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net<xmpp%3Adwd at dave.cridland.net>
>  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
>  - http://dave.cridland.net/
> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
>
> _______________________________________________
> JDev mailing list
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090429/783d9780/attachment.htm>

From will at netmindz.net  Wed Apr 29 17:04:51 2009
From: will at netmindz.net (Will Tatam)
Date: Wed, 29 Apr 2009 23:04:51 +0100
Subject: [jdev] (no subject)
In-Reply-To: <15169.1241036436.511912@puncture>
References: <49F8B45A.3030200@netmindz.net> <15169.1241036436.511912@puncture>
Message-ID: <49F8CF03.10007@netmindz.net>

On 29/04/09 21:20, Dave Cridland wrote:
> On Wed Apr 29 21:11:06 2009, Will Tatam wrote:
>> Anyone recommend any pre-existing flash xmpp conference clients ? I'm
>> looking at add a flash chatroom to a site
>>
>> I know I could build by own using XIFF but as i've not done and flash
>> in about 3 years a pre-existing one would be preferable
>
> Why Flash? Will Speeqe not do?
>
> Dave.

It has a whole stack of server dependencies, flash would just be client 
side plus XMPP server of choice, not python, django, postgresql ... etc

From koski.tuomas at gmail.com  Wed Apr 29 17:41:26 2009
From: koski.tuomas at gmail.com (Tuomas Koski)
Date: Thu, 30 Apr 2009 00:41:26 +0200
Subject: [jdev] Example PubSub -service to publish BBC World News
Message-ID: <1d142be30904291541p63221e61kd621e3718334f972@mail.gmail.com>

Hi guys and gals,

I'm kind of new to XMPP techniques and I'm a person who only learns by
"doing it my self" so:

I did a example PubSub service that publishes all the BBC World News
as they are published by BBC. There are 2 ways to subscribe to the
service:

1) add bbc-news at xmpp.lobstermonster.org to your XMPP roster
 OR
2) find "bbc_news" -node at pubsub.xmpp.lobstermonster.org and do the
needed PubSub subscriptions

The first option is more user friendly since you just need to add the
contact to you roster, and when you want to unsubscribe, you just
remove the bbc-news -users from your contacts. And this feature should
be provided by almost all the XMPP clients rather than easy to use
PubSub -functionalism.

The other difference in this service is that when a new item is
published to the node, user bbc-news at xmpp.lobstermonster.org will send
you the item also as "clear message". This is done so that the service
is usable even with gMail's client.

I also wrote a small story about it on my web site:
http://www.lobstermonster.org/post/xmpp-pubsub-service-to-publish-bbc-world-news

If you have any ideas how the service could work better, don't
hesitate to yell out loud! And if you want me to add your favorite RSS
feed to be able to be subscribed like this, I can do that too.


Cheers,
--
tuomas

ps. sorry if someone get's this mail twice, I send it also to the
pubsub -mailing list.

From dave at cridland.net  Thu Apr 30 03:19:09 2009
From: dave at cridland.net (Dave Cridland)
Date: Thu, 30 Apr 2009 09:19:09 +0100
Subject: [jdev] (no subject)
In-Reply-To: <49F8CF03.10007@netmindz.net>
References: <49F8B45A.3030200@netmindz.net>
	<15169.1241036436.511912@puncture> <49F8CF03.10007@netmindz.net>
Message-ID: <20772.1241079549.140220@puncture>

On Wed Apr 29 23:04:51 2009, Will Tatam wrote:
> It has a whole stack of server dependencies, flash would just be  
> client side plus XMPP server of choice, not python, django,  
> postgresql ... etc

Ah, I thought Speeqe just needed BOSH.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From sdk at disktree.net  Thu Apr 30 04:57:45 2009
From: sdk at disktree.net (tong)
Date: Thu, 30 Apr 2009 11:57:45 +0200
Subject: [jdev] Flash conference
In-Reply-To: <49F8B45A.3030200@netmindz.net>
References: <49F8B45A.3030200@netmindz.net>
Message-ID: <1241085465.23015.17.camel@mini>

On Wed, 2009-04-29 at 21:11 +0100, Will Tatam wrote:
> Anyone recommend any pre-existing flash xmpp conference clients ? I'm 
> looking at add a flash chatroom to a site
> 
> I know I could build by own using XIFF but as i've not done and flash in 
> about 3 years a pre-existing one would be preferable
> 

our (haxe) hxmpp library supports flash9+ and muchat too.
since haxe 2.03 you can also output SWCs for reuse with AS3.

latest source is here:
http://disktree.spektral.at/git/?a=summary&p=hxmpp

i am not aware of a 'ready to go' muc flash-component.

best.tong


> _______________________________________________
> JDev mailing list
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________


From stpeter at stpeter.im  Thu Apr 30 11:23:27 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 30 Apr 2009 10:23:27 -0600
Subject: [jdev] [Fwd: [Standards] Call for Experience: XEP-0138 (Stream
	Compression)]
Message-ID: <49F9D07F.1070604@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

FYI.

- -------- Original Message --------
Subject: [Standards] Call for Experience: XEP-0138 (Stream Compression)
Date: Thu, 30 Apr 2009 10:13:27 -0600
From: Peter Saint-Andre <stpeter at stpeter.im>
Reply-To: XMPP Standards <standards at xmpp.org>
To: XMPP Extension Discussion List <standards at xmpp.org>

In its meeting yesterday, the XMPP Council agreed to issue a "Call for
Experience" regarding XEP-0138 (Stream Compression), in preparation for
perhaps advancing this specification from Draft to Final in the XSF's
standards process. To help the Council decide whether this XEP is ready
to advance to a status of Final, the Council would like to gather the
following information:

1. Who has implemented XEP-0138? Please note that the protocol must be
implemented in at least two separate codebases (and preferably more).

2. Have developers experienced any problems with the protocol as defined
in XEP-0138? If so, please describe the problems and, if possible,
suggested solutions.

3. Is the text of XEP-0138 clear and unambiguous? Are more examples
necessary? Is the conformance language (MAY/SHOULD/MUST) appropriate?
Have developers found the text confusing at all? Please describe any
suggestions you have for improving the text.

If you have any comments about advancing XEP-0138 from Draft to Final in
the XSF's standards process, please provide them by the close of
business on Friday, May 22, 2009. After the Call for Experience, this
XEP might undergo revisions to address feedback received, after which it
will be presented to the XMPP Council for voting to a status of Final.

You can review the XEP here:

http://www.xmpp.org/extensions/xep-0138.html

Please send all feedback to the standards at xmpp.org list.

Thanks!

Peter

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn50H8ACgkQNL8k5A2w/vyMaACg5XwXGo1FslHvqO26oRqigDAG
81sAoOFI4uuIkfZtWoB4FZ90tk/LnAey
=9ga6
-----END PGP SIGNATURE-----

From stpeter at stpeter.im  Thu Apr 30 11:23:43 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 30 Apr 2009 10:23:43 -0600
Subject: [jdev] [Fwd: [Standards] Call for Experience: XEP-0199 (XMPP Ping)]
Message-ID: <49F9D08F.20502@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

FYI.

- -------- Original Message --------
Subject: [Standards] Call for Experience: XEP-0199 (XMPP Ping)
Date: Thu, 30 Apr 2009 10:16:40 -0600
From: Peter Saint-Andre <stpeter at stpeter.im>
Reply-To: XMPP Standards <standards at xmpp.org>
To: XMPP Extension Discussion List <standards at xmpp.org>

In its meeting yesterday, the XMPP Council agreed to issue a "Call for
Experience" regarding XEP-0199 (XMPP Ping), in preparation for perhaps
advancing this specification from Draft to Final in the XSF's standards
process. To help the Council decide whether this XEP is ready to advance
to a status of Final, the Council would like to gather the following
information:

1. Who has implemented XEP-0199? Please note that the protocol must be
implemented in at least two separate codebases (and preferably more).

2. Have developers experienced any problems with the protocol as defined
in XEP-0199? If so, please describe the problems and, if possible,
suggested solutions.

3. Is the text of XEP-0199 clear and unambiguous? Are more examples
needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? Have
developers found the text confusing at all? Please describe any
suggestions you have for improving the text.

If you have any comments about advancing XEP-0199 from Draft to Final,
please provide them by the close of business on Friday, May 22, 2009.
After the Call for Experience, this XEP might undergo revisions to
address feedback received, after which it will be presented to the XMPP
Council for voting to a status of Final.

You can review the XEP here:

http://www.xmpp.org/extensions/xep-0199.html

Please send all feedback to the standards at xmpp.org list.

Thanks!

Peter


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn50I8ACgkQNL8k5A2w/vx9fwCg54KWg3I1LQn+I5N+MCrJn9C1
b3QAn3YSYO5mA0xFnuiUiOqElnoRF42x
=jRup
-----END PGP SIGNATURE-----

From stpeter at stpeter.im  Thu Apr 30 12:13:21 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 30 Apr 2009 11:13:21 -0600
Subject: [jdev] server RFP for jabber.org IM service
Message-ID: <49F9DC31.30604@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The jabber.org admin team has decided to issue an RFP for the XMPP
server software that runs the jabber.org IM service. Full information is
available here:

http://www.jabber.org/index.php/2009/04/server-rfp/

Please let me know if you have any questions.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn53DEACgkQNL8k5A2w/vybYwCg95KrzeBp39c8zkDWLjnfqoBl
nT8Anis9q4SOCFdP20C01UFOk4ygbp6h
=XU1+
-----END PGP SIGNATURE-----

From jonathan.dickinson at k2.com  Wed Apr  1 06:52:14 2009
From: jonathan.dickinson at k2.com (Jonathan Dickinson)
Date: Wed, 1 Apr 2009 13:52:14 +0200
Subject: [jdev] APML and PubSub
Message-ID: <A790BE8D83ECC3469047C2E344EABE61027C5A3F725B@zamail01.k2workflow.com>

Hi All,

I thought someone might want to do something interesting with this technology.

""APML allows users to share their own personal Attention Profile in much the same way that OPML allows the exchange of reading lists between News Readers. The idea is to compress all forms of Attention Data into a portable file format containing a description of ranked user interests.""

Given an APML binding for each PubSub node (e.g. "user interface") a PubSub service could provide a user with a list of suggested nodes based on an APML document that they provide (via IQ or something): or automatically send them publications in any node based on each publications' tags.

Furthermore, if the PubSub spec got a little 'smarter' the author could set the 'affinity' for each post's tag: allowing them to indicate how well the post relates to the particular tag. This could be used to filter publications based on the "value" attribute in the APML. Thus:

Known APMLs:
Fred:
 Food 0.6
 User Interface 0.9
Jane
 Food 0.8
 User Interface 0.3

Subscriber Creates Publication:
 Food (3/5 = 0.6 - Invert = 0.4)
 Sends to  Fred and Jane
Another one:
 User Interface (2/5 = 0.4 - Invert = 0.6)
 Sends to  Fred

Just some hashing out of some ideas; I don't have the time to really go at it. Just wanted to throw it out there and see what you all think: maybe someone will hop on it and write a XEP.

<http://www.apml.org/>

-- Jonathan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090401/b6ae5a4e/attachment-0002.htm>

From mwild1 at gmail.com  Wed Apr  1 11:58:55 2009
From: mwild1 at gmail.com (Matthew Wild)
Date: Wed, 1 Apr 2009 17:58:55 +0100
Subject: [jdev] [ANN] Prosody 0.4.0 Released
Message-ID: <4db9cacb0904010958je6769fbm9b7bfdd2e6090e9@mail.gmail.com>

We are pleased to announce the release of Prosody 0.4.0.

It's no joke. We have spent most effort this release improving
Prosody internals, ensuring we have a solid base on which to build
future features. Numerous bugs have been fixed and we recommend
that all users of 0.3.0 upgrade.

That said, we do have a few new things in this release, namely
roster versioning (allowing clients to cache the roster, instead
of downloading it each time they connect) and support for external
components, allowing the use of gateways/transports and other services.

Prosody is a lightweight Jabber/XMPP server written in Lua. It aims
to be flexible, easy to extend, and simple to use for both users
and developers alike.

The following is a summary of changes since the previous version:

   * Numerous stability fixes (highly recommended 0.3 users upgrade)
   * XEP-0114 support for external components (experimental)
   * mod_xmlrpc: Allow RPC calls over HTTP/XMPP to command a server
   * Roster versioning, to allow faster logins (experimental)
   * Fix BOSH race condition with multiple idle sessions
   * Handle missing <priority> in initial client presence
   * Fix for correct pass-through of stanzas with prefixed attributes
   * Fix routing of some stanzas directed to bare JIDs
   * Config improvements, better error reporting, Include command
   * SASL ANONYMOUS support for anonymous login when enabled
   * mod_version now reports OS type (configurable)
   * MUC: Support PMs, vCards, and misc. reliability fixes
   * Module API: Add stanza.clone, timers, and more
   * Various logging improvements

We would appreciate feedback from those testing roster versioning -
we are aware of no clients that support it currently, but hopefully
that can soon change.

Testing external component support would greatly help too, there
are many different components, and we have only tried a couple.

All of the known issues listed in the previous release have been fixed.

Download: http://prosody.im/download/

Happy Jabbering,
  The Prosody Team


From simon at buddycloud.com  Wed Apr  1 14:10:21 2009
From: simon at buddycloud.com (Simon Tennant)
Date: Wed, 01 Apr 2009 21:10:21 +0200
Subject: [jdev] update on XMPP location (wherein beer is offered)
In-Reply-To: <28B8BE8DCC88448192FEF978639142CC@movsoftware.com>
References: <28B8BE8DCC88448192FEF978639142CC@movsoftware.com>
Message-ID: <49D3BC1D.90504@buddycloud.com>

Stephen Pendleton wrote:
> I like this a lot. How does the "nearby" query work? Does it returned
> bookmarked places that are owned by the submitting jid, or any bookmarked
> place nearby? What is "cellpatternquality" mean?
A place can have one of two modes.

    * Public places are those that can be shared with other people. Eg
      my placemark for Starbucks would be useful to others.
    * Private places are those that will not be shared with others. For
      example my placemark called "Home sweet home" is probably not
      useful to others on the network (and/or I want it to be private to
      just me and only shared with my friends).

butler.buddycloud.com will only show public in a nearby query. These
will be public places from all users. Additionally you can subscribe to
a place which then places it on your own list of places that you are
placed at in the future.

CellPatternQuality reflects the certainty of the place.  How "distinct"
it is. For example when you are driving the location butler will be
seeing lots of new wifi and cell towers. Saving a placemark at that
point will save it but it will be a "blurry" pattern in the database. 
Better would be to wait a moment, submit a couple more location queries,
watch for the cellpatternquality to increase to 100% and then send a
placemark save stanza.  Then the butler will be far more likely to
accurately place you back at that point in the future.

> Also, how does the component push my location to my PEP node if I am on
> another server? Would this be allowed by XMPP servers? I would be
> interested
> in seeing these stanzas though to test it out.
Indeed for non-buddycloud.com domains PEP would not work. There are two
solutions for this that we are looking at. Either:

    * having the remote non buddycloud node publish their own pep node
      after getting a reply to their location query stanza or
    * granting publisher rights to butler.buddycloud.com on your own
      pubsub geoloc node and passing the address to this node as part of
      the location query. The query results would then be published on
      your behalf in XEP-0080 (user location) format as well as being
      returned to the client.

> There is another application we are working on that involves XEP-0255. It
> currently supports what you are calling "beacon logs" stanzas to
> return back
> postal addresses. The system uses a combination of wifi access
> points/mobile
> towers to pinpoint your position and return back a lat/lon. It is very
> accurate in a populated area.
The butler does a best effort on the lookup of lat/long too and
publishes it as part of the XEP-0080 stack. I don't think we fill out
the post code for general locations (we do for known places) but this
could presumably be added with access to the right lat/long -> postcode
mapping tables.  It's not something that we have spent too much time on.
Our main efforts in butler development have focused on making location
something social by describing it as known places like home or work or
"on the road in munich" (travelling) or  "near  Jo's house" for example.

S.

-- 
Simon Tennant
Buddycloud
uk: +44 20 7043 6756               de: +49 89 420 955 854  
uk: +44 78 5335 6047               de: +49 17 8545 0880
email and xmpp: simon at buddycloud.com
http://buddycloud.com



From stpeter at stpeter.im  Thu Apr  2 20:23:31 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 02 Apr 2009 19:23:31 -0600
Subject: [jdev] jabber.org account registration policy
Message-ID: <49D56513.5080201@stpeter.im>

http://www.jabber.org/index.php/2009/04/account-registration-policy/ says:

The Jabber.org IM service has instituted a new account registration
policy. Until further notice, IM accounts can be registered only via the
web at register.jabber.org, which means that our longtime practice of
allowing in-band registration using an IM client has been disabled.

You will notice that register.jabber.org requires you to complete a
?CAPTCHA? test in order to create an account. This is a security measure
to help prevent bulk account creation by automated processes. We might
deploy further account security measures in the future, and will
announce any such changes at the jabber.org website.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090402/4f15d829/attachment-0002.bin>

From stpeter at stpeter.im  Thu Apr  2 23:17:08 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 02 Apr 2009 22:17:08 -0600
Subject: [jdev] client developers take note: list of IM services
Message-ID: <49D58DC4.3080601@stpeter.im>

Because of yet another jabber.org website change, we've moved the XML
file that provides an automated listing of the public XMPP servers.

Originally it was here: http://jabber.org/servers.xml

Then it was here: http://jabber.org/basicservers.xml

Now it is here: http://xmpp.org/services/services.xml

HTTP redirects are supposed to be in place, but there is no guarantee
that they are working. Please verify and let me know.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090402/e248cb6a/attachment-0002.bin>

From elmex at x-paste.de  Fri Apr  3 03:44:01 2009
From: elmex at x-paste.de (Robin Redeker)
Date: Fri, 3 Apr 2009 10:44:01 +0200
Subject: [jdev] client developers take note: list of IM services
In-Reply-To: <49D58DC4.3080601@stpeter.im>
References: <49D58DC4.3080601@stpeter.im>
Message-ID: <20090403084400.GB10294@kiste.laendle>

On Thu, Apr 02, 2009 at 10:17:08PM -0600, Peter Saint-Andre wrote:
> Because of yet another jabber.org website change, we've moved the XML
> file that provides an automated listing of the public XMPP servers.
> 
> Originally it was here: http://jabber.org/servers.xml
> 
> Then it was here: http://jabber.org/basicservers.xml
> 
> Now it is here: http://xmpp.org/services/services.xml
> 
> HTTP redirects are supposed to be in place, but there is no guarantee
> that they are working. Please verify and let me know.

http://www.jabber.org/servers.xml redirects to http://xmpp.org/software/servers.shtml

which is a list of server software...

And http://jabber.org/basicservers.xml is a redirect to http://www.jabber.org/basicservers.xml
which is a redirect to http://www.xmpp.org/services/services.xml

And http://xmpp.org/services/services.xml is 404 Not Found.

Greetings,
   Robin

-- 
Robin Redeker                         | Deliantra, the free code+content MORPG
elmex at ta-sa.org / r.redeker at gmail.com | http://www.deliantra.net
http://www.ta-sa.org/                 |


From stpeter at stpeter.im  Fri Apr  3 08:11:25 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 03 Apr 2009 07:11:25 -0600
Subject: [jdev] client developers take note: list of IM services
In-Reply-To: <20090403084400.GB10294@kiste.laendle>
References: <49D58DC4.3080601@stpeter.im>
	<20090403084400.GB10294@kiste.laendle>
Message-ID: <49D60AFD.2050707@stpeter.im>

On 4/3/09 2:44 AM, Robin Redeker wrote:
> On Thu, Apr 02, 2009 at 10:17:08PM -0600, Peter Saint-Andre wrote:
>> Because of yet another jabber.org website change, we've moved the XML
>> file that provides an automated listing of the public XMPP servers.
>>
>> Originally it was here: http://jabber.org/servers.xml
>>
>> Then it was here: http://jabber.org/basicservers.xml
>>
>> Now it is here: http://xmpp.org/services/services.xml
>>
>> HTTP redirects are supposed to be in place, but there is no guarantee
>> that they are working. Please verify and let me know.
> 
> http://www.jabber.org/servers.xml redirects to http://xmpp.org/software/servers.shtml

Fixed.

> which is a list of server software...
> 
> And http://jabber.org/basicservers.xml is a redirect to http://www.jabber.org/basicservers.xml
> which is a redirect to http://www.xmpp.org/services/services.xml

Fixed.

> And http://xmpp.org/services/services.xml is 404 Not Found.

Fixed.

Thanks for testing!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090403/c2a97e83/attachment-0002.bin>

From sander at sanderdevrieze.net  Fri Apr  3 11:34:35 2009
From: sander at sanderdevrieze.net (Sander Devrieze)
Date: Fri, 3 Apr 2009 18:34:35 +0200
Subject: [jdev] jabber.org account registration policy
In-Reply-To: <49D56513.5080201@stpeter.im>
References: <49D56513.5080201@stpeter.im>
Message-ID: <7b06a4100904030934i68b16cc2h8bedf5e9127c0ebb@mail.gmail.com>

2009/4/3 Peter Saint-Andre <stpeter at stpeter.im>:
> http://www.jabber.org/index.php/2009/04/account-registration-policy/ says:
>
> The Jabber.org IM service has instituted a new account registration
> policy. Until further notice, IM accounts can be registered only via the
> web at register.jabber.org, which means that our longtime practice of
> allowing in-band registration using an IM client has been disabled.

Would it be possible to remove jabber.org from
http://xmpp.org/services/services.xml ? I think that list makes no
sense when it contains services which are not in-band registration
capable...


-- 
Mvg, Sander Devrieze.


From lambda512 at gmail.com  Sat Apr  4 07:30:57 2009
From: lambda512 at gmail.com (naw)
Date: Sat, 4 Apr 2009 14:30:57 +0200
Subject: [jdev] jabber.org account registration policy
In-Reply-To: <7b06a4100904030934i68b16cc2h8bedf5e9127c0ebb@mail.gmail.com>
References: <49D56513.5080201@stpeter.im>
	<7b06a4100904030934i68b16cc2h8bedf5e9127c0ebb@mail.gmail.com>
Message-ID: <200904041430.58372.lambda512@gmail.com>

El Viernes 03 Abril 2009, Sander Devrieze escribi?:
> 2009/4/3 Peter Saint-Andre <stpeter at stpeter.im>:
> > http://www.jabber.org/index.php/2009/04/account-registration-policy/
> > says:
> >
> > The Jabber.org IM service has instituted a new account registration
> > policy. Until further notice, IM accounts can be registered only via the
> > web at register.jabber.org, which means that our longtime practice of
> > allowing in-band registration using an IM client has been disabled.
>
> Would it be possible to remove jabber.org from
> http://xmpp.org/services/services.xml ? I think that list makes no
> sense when it contains services which are not in-band registration
> capable...

I think that it mades sense to have a list of federated servers. It can be 
useful for other things. But maybe there should be some aditional information 
about the servers (if they support in-band registration), or maybe several 
lists (e.g. one for all servers, another one for servers wich support 
in-band...)

Also, if in-band registration is going to be less used by servers until the 
implementation of XEP-0158 (captchas) in servers and clients, it could be 
also useful to provide the registration address as a child element in the 
list.

-- 

Jabber-ID: lambda512 at jabberes.org lambda512 at gmail.com


From stpeter at stpeter.im  Sat Apr  4 14:13:31 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Sat, 04 Apr 2009 13:13:31 -0600
Subject: [jdev] jabber.org account registration policy
In-Reply-To: <200904041430.58372.lambda512@gmail.com>
References: <49D56513.5080201@stpeter.im>	<7b06a4100904030934i68b16cc2h8bedf5e9127c0ebb@mail.gmail.com>
	<200904041430.58372.lambda512@gmail.com>
Message-ID: <49D7B15B.8070902@stpeter.im>

On 4/4/09 6:30 AM, naw wrote:
> El Viernes 03 Abril 2009, Sander Devrieze escribi?:
>> 2009/4/3 Peter Saint-Andre <stpeter at stpeter.im>:
>>> http://www.jabber.org/index.php/2009/04/account-registration-policy/
>>> says:
>>>
>>> The Jabber.org IM service has instituted a new account registration
>>> policy. Until further notice, IM accounts can be registered only via the
>>> web at register.jabber.org, which means that our longtime practice of
>>> allowing in-band registration using an IM client has been disabled.
>> Would it be possible to remove jabber.org from
>> http://xmpp.org/services/services.xml ? I think that list makes no
>> sense when it contains services which are not in-band registration
>> capable...

Done.

> I think that it mades sense to have a list of federated servers. It can be 
> useful for other things. But maybe there should be some aditional information 
> about the servers (if they support in-band registration), or maybe several 
> lists (e.g. one for all servers, another one for servers wich support 
> in-band...)

I think it's best if services.xml includes only services that support
in-band registration (IBR), because this file is used by clients to
present a list of services for account registration.

> Also, if in-band registration is going to be less used by servers until the 
> implementation of XEP-0158 (captchas) in servers and clients, it could be 
> also useful to provide the registration address as a child element in the 
> list.

Given the recent (and growing) problems with automated processes
registering large numbers of accounts on public XMPP services, I think
that IBR will soon become unworkable without XEP-0158 support in clients
and servers. Until that happens, we will diable IBR at jabber.org (and I
expect many other public XMPP services to do the same). IBR was a great
idea back in 1999 when no one had ever heard of Jabber, but these days
it is very close to hazardous for the health of the network.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090404/cac8fa3e/attachment-0002.bin>

From mikemendel at gmail.com  Sat Apr  4 16:00:06 2009
From: mikemendel at gmail.com (mikemendel)
Date: Sat,  4 Apr 2009 16:00:06 -0500 (CDT)
Subject: [jdev] mikemendel has invited you to join SlideShare
Message-ID: <20090404210006.ACF9E21AD64@atlas.jabber.org>

An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090404/aa6fde85/attachment-0002.htm>

From pendleto at movsoftware.com  Mon Apr  6 09:57:23 2009
From: pendleto at movsoftware.com (Stephen Pendleton)
Date: Mon, 6 Apr 2009 10:57:23 -0400
Subject: [jdev] update on XMPP location (wherein beer is offered)
In-Reply-To: <49D3BC1D.90504@buddycloud.com>
Message-ID: <9090DBE6366A4B5C8CEEC37CC2799F1C@movsoftware.com>

I can't seem to get this to work. For example I send:

<iq to="butler.buddycloud.com" type="get" xml:lang="en" id="location1">
	<locationquery xmlns="urn:xmpp:locationquery:0">
		<timestamp>2009-04-05T08:09:56Z</timestamp>
		<publish>true</publish>
		<reference>
			<id>262:07:51520:34124757</id>
			<type>cell</type>
			<signalstrength>88</signalstrength>
		</reference>		
	</locationquery>
	<locationquery xmlns="urn:xmpp:locationquery:0">
		<timestamp>2009-04-05T08:09:56Z</timestamp>
		<reference>
			<id>262:07:51520:34104756</id>
			<type>cell</type>
			<signalstrength>88</signalstrength>
		</reference>		
	</locationquery>
	<locationquery xmlns="urn:xmpp:locationquery:0">
		<timestamp>2009-04-05T08:09:56Z</timestamp>
		<reference>
			<id>262:07:51520:34084753</id>
			<type>cell</type>
			<signalstrength>88</signalstrength>
		</reference>		
	</locationquery>
</iq>
and I get back the placename OK. I then send the nearby places query and get
an error back:

<iq to="butler.buddycloud.com" type="get" id="nearbyplaces1">
	<command xmlns="http://jabber.org/protocol/commands"
node="location">
		<x xmlns="jabber:x:data" type="form">
			<field type="hidden" var="FORM_TYPE">
	
<value>buddycloud:location:places_near</value>
			</field>
		</x>
	</command>
</iq>

and get back:
<iq from="butler.buddycloud.com" to="spendleton at movsoftware.com/spark"
id="nearbyplaces1" type="error" xml:lang="en-GB">
	<command xmlns="http://jabber.org/protocol/commands"
node="location">
		<x xmlns="jabber:x:data" type="form">
			<field type="hidden" var="FORM_TYPE">
	
<value>buddycloud:location:places_near</value>
			</field>
		</x>
	</command>
<error code="500" type="wait"><internal-server-error
xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/><text
xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/></error></iq>


Also, I dont understand the <publish>true</publish> stanza. In the case
where I am sending cellids what is it publishing to my PEP node? Not my
lat/lon right, because you do not have lat/lon mappings from cellids to
lat/long coordinates and I dont have a placename published with that
lat/lon.

Also, if I remove or set the <publish> to <publish>false</publish> I get
back:

iq from="butler.buddycloud.com" to="spendleton at movsoftware.com/spark"
id="location31" type="result"><geoloc
xmlns="http://jabber.org/protocol/geoloc"
xml:lang="en"><accuracy>1000000</accuracy></geoloc></iq>

Not sure what this means.

Thanks
-----Original Message-----
From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] On Behalf Of
Simon Tennant
Sent: 04/01/2009 3:10 PM
To: Jabber/XMPP software development list
Subject: Re: [jdev] update on XMPP location (wherein beer is offered)


Stephen Pendleton wrote:
> I like this a lot. How does the "nearby" query work? Does it returned 
> bookmarked places that are owned by the submitting jid, or any 
> bookmarked place nearby? What is "cellpatternquality" mean?
A place can have one of two modes.

    * Public places are those that can be shared with other people. Eg
      my placemark for Starbucks would be useful to others.
    * Private places are those that will not be shared with others. For
      example my placemark called "Home sweet home" is probably not
      useful to others on the network (and/or I want it to be private to
      just me and only shared with my friends).

butler.buddycloud.com will only show public in a nearby query. These will be
public places from all users. Additionally you can subscribe to a place
which then places it on your own list of places that you are placed at in
the future.

CellPatternQuality reflects the certainty of the place.  How "distinct" it
is. For example when you are driving the location butler will be seeing lots
of new wifi and cell towers. Saving a placemark at that point will save it
but it will be a "blurry" pattern in the database. 
Better would be to wait a moment, submit a couple more location queries,
watch for the cellpatternquality to increase to 100% and then send a
placemark save stanza.  Then the butler will be far more likely to
accurately place you back at that point in the future.

> Also, how does the component push my location to my PEP node if I am 
> on another server? Would this be allowed by XMPP servers? I would be 
> interested in seeing these stanzas though to test it out.
Indeed for non-buddycloud.com domains PEP would not work. There are two
solutions for this that we are looking at. Either:

    * having the remote non buddycloud node publish their own pep node
      after getting a reply to their location query stanza or
    * granting publisher rights to butler.buddycloud.com on your own
      pubsub geoloc node and passing the address to this node as part of
      the location query. The query results would then be published on
      your behalf in XEP-0080 (user location) format as well as being
      returned to the client.

> There is another application we are working on that involves XEP-0255. 
> It currently supports what you are calling "beacon logs" stanzas to 
> return back postal addresses. The system uses a combination of wifi 
> access points/mobile
> towers to pinpoint your position and return back a lat/lon. It is very
> accurate in a populated area.
The butler does a best effort on the lookup of lat/long too and publishes it
as part of the XEP-0080 stack. I don't think we fill out the post code for
general locations (we do for known places) but this could presumably be
added with access to the right lat/long -> postcode mapping tables.  It's
not something that we have spent too much time on. Our main efforts in
butler development have focused on making location something social by
describing it as known places like home or work or "on the road in munich"
(travelling) or  "near  Jo's house" for example.

S.

-- 
Simon Tennant
Buddycloud
uk: +44 20 7043 6756               de: +49 89 420 955 854  
uk: +44 78 5335 6047               de: +49 17 8545 0880
email and xmpp: simon at buddycloud.com
http://buddycloud.com

_______________________________________________
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: JDev-unsubscribe at jabber.org
_______________________________________________




From helge at buddycloud.com  Mon Apr  6 13:33:27 2009
From: helge at buddycloud.com (Helge Timenes)
Date: Mon, 06 Apr 2009 20:33:27 +0200
Subject: [jdev] update on XMPP location (wherein beer is offered)
In-Reply-To: <9090DBE6366A4B5C8CEEC37CC2799F1C@movsoftware.com>
References: <9090DBE6366A4B5C8CEEC37CC2799F1C@movsoftware.com>
Message-ID: <49DA4AF7.1080806@buddycloud.com>

Stephen Pendleton wrote:
> I can't seem to get this to work. For example I send:
>
> <iq to="butler.buddycloud.com" type="get" xml:lang="en" id="location1">
> 	<locationquery xmlns="urn:xmpp:locationquery:0">
> 		<timestamp>2009-04-05T08:09:56Z</timestamp>
> 		<publish>true</publish>
> 		<reference>
> 			<id>262:07:51520:34124757</id>
> 			<type>cell</type>
> 			<signalstrength>88</signalstrength>
> 		</reference>		
> 	</locationquery>
> 	<locationquery xmlns="urn:xmpp:locationquery:0">
> 		<timestamp>2009-04-05T08:09:56Z</timestamp>
> 		<reference>
> 			<id>262:07:51520:34104756</id>
> 			<type>cell</type>
> 			<signalstrength>88</signalstrength>
> 		</reference>		
> 	</locationquery>
> 	<locationquery xmlns="urn:xmpp:locationquery:0">
> 		<timestamp>2009-04-05T08:09:56Z</timestamp>
> 		<reference>
> 			<id>262:07:51520:34084753</id>
> 			<type>cell</type>
> 			<signalstrength>88</signalstrength>
> 		</reference>		
> 	</locationquery>
> </iq>
>   
At the moment our server don't like multiple <locationquery> elements in 
an <iq>. There is no particularly good reason for this and I will fix it.

> and I get back the placename OK. I then send the nearby places query and get
> an error back:
>
> <iq to="butler.buddycloud.com" type="get" id="nearbyplaces1">
> 	<command xmlns="http://jabber.org/protocol/commands"
> node="location">
> 		<x xmlns="jabber:x:data" type="form">
> 			<field type="hidden" var="FORM_TYPE">
> 	
> <value>buddycloud:location:places_near</value>
> 			</field>
> 		</x>
> 	</command>
> </iq>
>
> and get back:
> <iq from="butler.buddycloud.com" to="spendleton at movsoftware.com/spark"
> id="nearbyplaces1" type="error" xml:lang="en-GB">
> 	<command xmlns="http://jabber.org/protocol/commands"
> node="location">
> 		<x xmlns="jabber:x:data" type="form">
> 			<field type="hidden" var="FORM_TYPE">
> 	
> <value>buddycloud:location:places_near</value>
> 			</field>
> 		</x>
> 	</command>
> <error code="500" type="wait"><internal-server-error
> xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/><text
> xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/></error></iq>
>
>
>   
Something wrong was probably not right there (!) Possibly to do with the 
above.
> Also, I dont understand the <publish>true</publish> stanza. In the case
> where I am sending cellids what is it publishing to my PEP node? Not my
> lat/lon right, because you do not have lat/lon mappings from cellids to
> lat/long coordinates and I dont have a placename published with that
> lat/lon.
>   
It will publish as much info as can be derived from your references. We 
do have a rudimentary cell to lat/lon database, and if a match is found 
it wil use this to derive your coordinates. If not it will default to 
the center of your country (derived from MCC) associated with a huuuuge 
error. From lat/lon it will try to obtain region, city and area names 
(with a little help from geonames.org).

Note that the publish will most likely fail, since your host server will 
propably let our server publish to your PEP node on your behalf. Some 
configuration might be needed for this to work I believe.
> Also, if I remove or set the <publish> to <publish>false</publish> I get
> back:
>
> iq from="butler.buddycloud.com" to="spendleton at movsoftware.com/spark"
> id="location31" type="result"><geoloc
> xmlns="http://jabber.org/protocol/geoloc"
> xml:lang="en"><accuracy>1000000</accuracy></geoloc></iq>
>
> Not sure what this means.
>   
This is probably related to your error above. Some how no results could 
be found (even so it suggest an error for your location had it been 
found. Er...  right)
> Thanks
>   
Your're welcome


From gnauck at ag-software.de  Mon Apr  6 14:10:58 2009
From: gnauck at ag-software.de (Alexander Gnauck)
Date: Mon, 06 Apr 2009 21:10:58 +0200
Subject: [jdev] XSF membership application period Q2/2009
Message-ID: <49DA53C2.90006@ag-software.de>

The XMPP Standards Foundation (XSF) is currently holding its quarterly 
membership application period:
http://wiki.xmpp.org/web/Membership_Applications_April_2009

Applications are encouraged from developers and others who are actively 
involved in the Jabber/XMPP community. To apply, create a page about 
yourself on the wiki.

If you don't have a wiki account, send your name, preferred nickname and
email address to me or one of the other Sysops:
http://wiki.xmpp.org/index.php/Sysops

The application period ends on 22th April 2009 23:59h UTC, so apply today!

Regards,
Alex
--
Alexander Gnauck
xmpp:gnauck at jabber.org


From waqas20 at gmail.com  Mon Apr  6 14:27:08 2009
From: waqas20 at gmail.com (Waqas Hussain)
Date: Tue, 7 Apr 2009 00:27:08 +0500
Subject: [jdev] update on XMPP location (wherein beer is offered)
In-Reply-To: <49DA4AF7.1080806@buddycloud.com>
References: <9090DBE6366A4B5C8CEEC37CC2799F1C@movsoftware.com>
	<49DA4AF7.1080806@buddycloud.com>
Message-ID: <7fc4fa880904061227k7a31a66fxea5375a3d196af5b@mail.gmail.com>

On Mon, Apr 6, 2009 at 11:33 PM, Helge Timenes <helge at buddycloud.com> wrote:
> Stephen Pendleton wrote:
>> I can't seem to get this to work. For example I send:
>>
>> <iq to="butler.buddycloud.com" type="get" xml:lang="en" id="location1">
>> ? ? ? <locationquery xmlns="urn:xmpp:locationquery:0">
>> ? ? ? ? ? ? ? <timestamp>2009-04-05T08:09:56Z</timestamp>
>> ? ? ? ? ? ? ? <publish>true</publish>
>> ? ? ? ? ? ? ? <reference>
>> ? ? ? ? ? ? ? ? ? ? ? <id>262:07:51520:34124757</id>
>> ? ? ? ? ? ? ? ? ? ? ? <type>cell</type>
>> ? ? ? ? ? ? ? ? ? ? ? <signalstrength>88</signalstrength>
>> ? ? ? ? ? ? ? </reference>
>> ? ? ? </locationquery>
>> ? ? ? <locationquery xmlns="urn:xmpp:locationquery:0">
>> ? ? ? ? ? ? ? <timestamp>2009-04-05T08:09:56Z</timestamp>
>> ? ? ? ? ? ? ? <reference>
>> ? ? ? ? ? ? ? ? ? ? ? <id>262:07:51520:34104756</id>
>> ? ? ? ? ? ? ? ? ? ? ? <type>cell</type>
>> ? ? ? ? ? ? ? ? ? ? ? <signalstrength>88</signalstrength>
>> ? ? ? ? ? ? ? </reference>
>> ? ? ? </locationquery>
>> ? ? ? <locationquery xmlns="urn:xmpp:locationquery:0">
>> ? ? ? ? ? ? ? <timestamp>2009-04-05T08:09:56Z</timestamp>
>> ? ? ? ? ? ? ? <reference>
>> ? ? ? ? ? ? ? ? ? ? ? <id>262:07:51520:34084753</id>
>> ? ? ? ? ? ? ? ? ? ? ? <type>cell</type>
>> ? ? ? ? ? ? ? ? ? ? ? <signalstrength>88</signalstrength>
>> ? ? ? ? ? ? ? </reference>
>> ? ? ? </locationquery>
>> </iq>
>>
> At the moment our server don't like multiple <locationquery> elements in
> an <iq>. There is no particularly good reason for this and I will fix it.
>

There is a particularly good reason for this: IQ gets and sets are
only allowed to have a single child.

Don't 'fix' this, because accepting multiple IQ children would break
the XMPP spec.

--
Waqas Hussain


From helge at buddycloud.com  Mon Apr  6 14:40:49 2009
From: helge at buddycloud.com (Helge Timenes)
Date: Mon, 06 Apr 2009 21:40:49 +0200
Subject: [jdev] update on XMPP location (wherein beer is offered)
In-Reply-To: <7fc4fa880904061227k7a31a66fxea5375a3d196af5b@mail.gmail.com>
References: <9090DBE6366A4B5C8CEEC37CC2799F1C@movsoftware.com>	<49DA4AF7.1080806@buddycloud.com>
	<7fc4fa880904061227k7a31a66fxea5375a3d196af5b@mail.gmail.com>
Message-ID: <49DA5AC1.6050602@buddycloud.com>

Waqas Hussain wrote:
> On Mon, Apr 6, 2009 at 11:33 PM, Helge Timenes <helge at buddycloud.com> wrote:
>   
>> Stephen Pendleton wrote:
>>     
>>> I can't seem to get this to work. For example I send:
>>>
>>> <iq to="butler.buddycloud.com" type="get" xml:lang="en" id="location1">
>>>       <locationquery xmlns="urn:xmpp:locationquery:0">
>>>               <timestamp>2009-04-05T08:09:56Z</timestamp>
>>>               <publish>true</publish>
>>>               <reference>
>>>                       <id>262:07:51520:34124757</id>
>>>                       <type>cell</type>
>>>                       <signalstrength>88</signalstrength>
>>>               </reference>
>>>       </locationquery>
>>>       <locationquery xmlns="urn:xmpp:locationquery:0">
>>>               <timestamp>2009-04-05T08:09:56Z</timestamp>
>>>               <reference>
>>>                       <id>262:07:51520:34104756</id>
>>>                       <type>cell</type>
>>>                       <signalstrength>88</signalstrength>
>>>               </reference>
>>>       </locationquery>
>>>       <locationquery xmlns="urn:xmpp:locationquery:0">
>>>               <timestamp>2009-04-05T08:09:56Z</timestamp>
>>>               <reference>
>>>                       <id>262:07:51520:34084753</id>
>>>                       <type>cell</type>
>>>                       <signalstrength>88</signalstrength>
>>>               </reference>
>>>       </locationquery>
>>> </iq>
>>>
>>>       
>> At the moment our server don't like multiple <locationquery> elements in
>> an <iq>. There is no particularly good reason for this and I will fix it.
>>
>>     
>
> There is a particularly good reason for this: IQ gets and sets are
> only allowed to have a single child.
>
> Don't 'fix' this, because accepting multiple IQ children would break
> the XMPP spec.
>
>   
Right, silly of me. Fix cancelled.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090406/dd6fc296/attachment-0002.htm>

From fippo at goodadvice.pages.de  Mon Apr  6 14:42:49 2009
From: fippo at goodadvice.pages.de (Philipp Hancke)
Date: Mon, 06 Apr 2009 21:42:49 +0200
Subject: [jdev] update on XMPP location (wherein beer is offered)
In-Reply-To: <7fc4fa880904061227k7a31a66fxea5375a3d196af5b@mail.gmail.com>
References: <9090DBE6366A4B5C8CEEC37CC2799F1C@movsoftware.com>	<49DA4AF7.1080806@buddycloud.com>
	<7fc4fa880904061227k7a31a66fxea5375a3d196af5b@mail.gmail.com>
Message-ID: <49DA5B39.8050905@goodadvice.pages.de>

Waqas Hussain wrote:
> There is a particularly good reason for this: IQ gets and sets are
> only allowed to have a single child.
> 
> Don't 'fix' this, because accepting multiple IQ children would break
> the XMPP spec.

and because XEP 0255 - example 7 shows the right way to do it.


From pendleto at movsoftware.com  Mon Apr  6 15:12:09 2009
From: pendleto at movsoftware.com (Stephen Pendleton)
Date: Mon, 6 Apr 2009 16:12:09 -0400
Subject: [jdev] update on XMPP location (wherein beer is offered)
In-Reply-To: <7fc4fa880904061227k7a31a66fxea5375a3d196af5b@mail.gmail.com>
Message-ID: <693A5CF4B33B4EBBB0913659D3F8F147@movsoftware.com>

My mistake. I meant to say I sent:

<iq to="butler.buddycloud.com" type="get" xml:lang="en" id="location1">
	<locationquery xmlns="urn:xmpp:locationquery:0">
		<reference>
			<id>262:07:51520:34124757</id>
			<type>cell</type>
			<signalstrength>88</signalstrength>
		</reference>		
		<reference>
			<id>262:07:51520:34104756</id>
			<type>cell</type>
			<signalstrength>88</signalstrength>
		</reference>		
		<reference>
			<id>262:07:51520:34084753</id>
			<type>cell</type>
			<signalstrength>88</signalstrength>
		</reference>		
	</locationquery>
</iq>

-----Original Message-----
From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] On Behalf Of
Waqas Hussain
Sent: 04/06/2009 3:27 PM
To: Jabber/XMPP software development list
Subject: Re: [jdev] update on XMPP location (wherein beer is offered)


On Mon, Apr 6, 2009 at 11:33 PM, Helge Timenes <helge at buddycloud.com> wrote:
> Stephen Pendleton wrote:
>> I can't seem to get this to work. For example I send:
>>
>> <iq to="butler.buddycloud.com" type="get" xml:lang="en" 
>> id="location1">
>> ? ? ? <locationquery xmlns="urn:xmpp:locationquery:0">
>> ? ? ? ? ? ? ? <timestamp>2009-04-05T08:09:56Z</timestamp>
>> ? ? ? ? ? ? ? <publish>true</publish>
>> ? ? ? ? ? ? ? <reference>
>> ? ? ? ? ? ? ? ? ? ? ? <id>262:07:51520:34124757</id>
>> ? ? ? ? ? ? ? ? ? ? ? <type>cell</type>
>> ? ? ? ? ? ? ? ? ? ? ? <signalstrength>88</signalstrength>
>> ? ? ? ? ? ? ? </reference>
>> ? ? ? </locationquery>
>> ? ? ? <locationquery xmlns="urn:xmpp:locationquery:0">
>> ? ? ? ? ? ? ? <timestamp>2009-04-05T08:09:56Z</timestamp>
>> ? ? ? ? ? ? ? <reference>
>> ? ? ? ? ? ? ? ? ? ? ? <id>262:07:51520:34104756</id>
>> ? ? ? ? ? ? ? ? ? ? ? <type>cell</type>
>> ? ? ? ? ? ? ? ? ? ? ? <signalstrength>88</signalstrength>
>> ? ? ? ? ? ? ? </reference>
>> ? ? ? </locationquery>
>> ? ? ? <locationquery xmlns="urn:xmpp:locationquery:0">
>> ? ? ? ? ? ? ? <timestamp>2009-04-05T08:09:56Z</timestamp>
>> ? ? ? ? ? ? ? <reference>
>> ? ? ? ? ? ? ? ? ? ? ? <id>262:07:51520:34084753</id>
>> ? ? ? ? ? ? ? ? ? ? ? <type>cell</type>
>> ? ? ? ? ? ? ? ? ? ? ? <signalstrength>88</signalstrength>
>> ? ? ? ? ? ? ? </reference>
>> ? ? ? </locationquery>
>> </iq>
>>
> At the moment our server don't like multiple <locationquery> elements 
> in an <iq>. There is no particularly good reason for this and I will 
> fix it.
>

There is a particularly good reason for this: IQ gets and sets are only
allowed to have a single child.

Don't 'fix' this, because accepting multiple IQ children would break the
XMPP spec.

--
Waqas Hussain
_______________________________________________
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: JDev-unsubscribe at jabber.org
_______________________________________________




From stpeter at stpeter.im  Mon Apr  6 23:20:45 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 06 Apr 2009 22:20:45 -0600
Subject: [jdev] jabber disk ?
In-Reply-To: <200903222325.n2MNPGCE017257@zogzog.maillard.mobi>
References: <200903222325.n2MNPGCE017257@zogzog.maillard.mobi>
Message-ID: <49DAD49D.2000707@stpeter.im>

On 3/22/09 5:25 PM, Xavier Maillard wrote:
> Hi,
> 
> I am writting a text editor with the aim to publish
> notes/articles/whatever over XMPP. I have all the basic editor
> stuff working and now has come the time to choose how to
> effectively "publish" these texts.
> 
> My goal behind this, is to have access to my notes anywhere at
> anytime. I am not sure what the best method I should choose to
> store all this stuff. I know there were tries to have webdav over
> XMPP, I know there is pubsub (which has my preference)  and
> lately I felt upon something called "jabdisk". I am looking for
> information about the later.
> 
> OTOH, if you have any idea on a global storage strategy for my
> client, feel free to share them :)
> 
> My main interest in writing this software is to be able to run a
> "jabber site" (aka a website) totally via XMPP and particulary a
> "XMPP wiki".

Why? Isn't that what HTTP is for?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090406/5640f1a3/attachment-0002.bin>

From christopher.zorn at gmail.com  Wed Apr  8 10:29:08 2009
From: christopher.zorn at gmail.com (Christopher Zorn)
Date: Wed, 8 Apr 2009 11:29:08 -0400
Subject: [jdev] ANN. Couchdb Backend
Message-ID: <149014b90904080829g642de4e4l684b530a0a6e7cbd@mail.gmail.com>

Just wanted to announce that I started a couchdb backend for ejabberd.

I did not create a ticket because I did not know if it fit. Also, it would
be nice to see how many people are interested in it before it is formal.

It is located on github.

http://thetofu.com/archive/ejabberd_couchdb_20090407.html
http://github.com/twonds/ejabberd_couchdb/tree/master

Relax and enjoy. ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090408/61894de8/attachment-0002.htm>

From thiranjith at gmail.com  Wed Apr  8 14:26:12 2009
From: thiranjith at gmail.com (Thiranjith .)
Date: Thu, 9 Apr 2009 07:26:12 +1200
Subject: [jdev] Using XMPP to talk to a mobile client
Message-ID: <2ec5902e0904081226v734582e9ib30ebca6c2f7ce18@mail.gmail.com>

Hi,

Can we use XMPP to talk to a client on a mobile device (e.g. PDA/ mobile
phone) that is connected to the internet using 3G? From what I understand,
phones' end-point IP changes as they move around, and generally they are
behind the network operator's (At&T, Vodafone etc) firewall.

Say that user 'A' sends a message to our mobile client. From what I
understand, the message will go through the XMPP server (e.g. Jabber.org or
our own) to find where our client is, so it can route the message. How would
the XMPP server know where to find our client in the place? The IP our
client used when registering with the server could be different now because
it could have moved around.

Does the mobile client need to periodically notify the server about its IP?
>From what I understand, the BOSH technique described in
http://xmpp.org/extensions/xep-0124.html#intro is meant to address this, but
it seems to work only if the entity behind the firewall initiate the
connection first (in this case, the client running within the mobile phone).

Please correct me if I got all this wrong as I am new to XMPP, but I would
greately appreciate if anyone can explain how the xmpp server finds the
mobile client that is on the move. Does our sever needs to implement that
routing logic ourselves? Any articles explaining this would also be great!

Thank you!
Thira
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090409/3193c548/attachment-0001.htm>

From stpeter at stpeter.im  Wed Apr  8 14:44:11 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 08 Apr 2009 13:44:11 -0600
Subject: [jdev] Monthly XMPP Meeting #2
Message-ID: <49DCFE8B.3080201@stpeter.im>

Although I never sent out minutes from the first "Monthly XMPP Meeting",
I think it would be productive to hold another meeting again soon. I
propose next Tuesday, April 14, at 20:00 UTC (check your local times!)
in the jdev at conference.jabber.org room.

See you there!

Peter

P.S. Maybe I'll get a change to write up the minutes from MXM #1 before
then:

http://logs.jabber.org/jdev at conference.jabber.org/2009-03-12.html


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090408/e8235b02/attachment-0002.bin>

From fabio.forno at gmail.com  Wed Apr  8 16:37:47 2009
From: fabio.forno at gmail.com (Fabio Forno)
Date: Wed, 8 Apr 2009 23:37:47 +0200
Subject: [jdev] Using XMPP to talk to a mobile client
In-Reply-To: <2ec5902e0904081226v734582e9ib30ebca6c2f7ce18@mail.gmail.com>
References: <2ec5902e0904081226v734582e9ib30ebca6c2f7ce18@mail.gmail.com>
Message-ID: <2fd53c3a0904081437q2d364a2w8e0b69d5b404a00@mail.gmail.com>

On Wed, Apr 8, 2009 at 9:26 PM, Thiranjith . <thiranjith at gmail.com> wrote:
> Hi,
>
> Can we use XMPP to talk to a client on a mobile device (e.g. PDA/ mobile
> phone) that is connected to the internet using 3G? From what I understand,
> phones' end-point IP changes as they move around, and generally they are
> behind the network operator's (At&T, Vodafone etc) firewall.
>
> Say that user 'A' sends a message to our mobile client. From what I
> understand, the message will go through the XMPP server (e.g. Jabber.org or
> our own) to find where our client is, so it can route the message. How would
> the XMPP server know where to find our client in the place? The IP our
> client used when registering with the server could be different now because
> it could have moved around.

As far as you are online with your client a socket is being kept open
with the server, thus allowing to push stanzas to your device. No need
to communicate your IP, just listen for incoming messages. You may try
one of the several clients listed here
http://xmpp.org/software/clients.shtml#mobile

Most networks will maintain your IP while moving to different cells,
and if you get disconnected it's up to the client to reopen a session
with the server

The situation is different while you are disconnected. In that case
the server stores the messages in the offline storage until the client
goes online

If you have urgent messages you can use an SMS for automatically
waking up the client, however this is a service that has a cost


> Does the mobile client need to periodically notify the server about its IP?
> From what I understand, the BOSH technique described in
> http://xmpp.org/extensions/xep-0124.html#intro is meant to address this, but
> it seems to work only if the entity behind the firewall initiate the
> connection first (in this case, the client running within the mobile phone).

BOSH likes tecniques are just used to pass through proxies or run
clients in web browsers. They may be used in order to improve
connection reliability, but a new and better method (xep-0198) is
being defined for this purpose.

-- 
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: ff at jabber.bluendo.com


From jonathan.dickinson at k2.com  Thu Apr  9 02:28:24 2009
From: jonathan.dickinson at k2.com (Jonathan Dickinson)
Date: Thu, 9 Apr 2009 09:28:24 +0200
Subject: [jdev] Using XMPP to talk to a mobile client
In-Reply-To: <2fd53c3a0904081437q2d364a2w8e0b69d5b404a00@mail.gmail.com>
References: <2ec5902e0904081226v734582e9ib30ebca6c2f7ce18@mail.gmail.com>
	<2fd53c3a0904081437q2d364a2w8e0b69d5b404a00@mail.gmail.com>
Message-ID: <A790BE8D83ECC3469047C2E344EABE61027C6442096B@zamail01.k2workflow.com>

> -----Original Message-----
> From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] On
> Behalf Of Fabio Forno
> Sent: 08 April 2009 11:38 PM
> To: Jabber/XMPP software development list
> Subject: Re: [jdev] Using XMPP to talk to a mobile client
> 
> On Wed, Apr 8, 2009 at 9:26 PM, Thiranjith . <thiranjith at gmail.com>
> wrote:
> > Hi,
> >
> > Can we use XMPP to talk to a client on a mobile device (e.g. PDA/
> mobile
> > phone) that is connected to the internet using 3G? From what I
> understand,
> > phones' end-point IP changes as they move around, and generally they
> are
> > behind the network operator's (At&T, Vodafone etc) firewall.
> >

IPv6 is supposed to address situations in regard to mobile devices. Although I am not entirely sure how well the technologies have been deployed. IIRC most mobile operators use NAT to connect clients to the internet, this means that the NAT will do what it can to keep your socket connections alive - in other words, mobile devices are less reliable (because they can lose signal entirely), but still completely viable (because the operators generally have this kind of stuff in mind).

My Windows Mobile phone has IPv6 and I have been able to access the IPv6 test website - if it works in a backwards country like South Africa it's gotta work in America and the UK!!!
 
> > Does the mobile client need to periodically notify the server about
> its IP?

No and yes. As I said this should be handled by your operator's NAT: test the system and find out (connect to a XMPP server and go on a road trip). If it isn't you should definitely raise a stink.

Yes in terms that, primarily, if your public IP (i.e. one of your operator's IP addresses) changes chances are you are going to get clean disconnected. If this happens your client should reconnect automatically - and as a side effect of this the server gets your new IP.

> 
> --
> Fabio Forno, Ph.D.
> Bluendo srl http://www.bluendo.com
> jabber id: ff at jabber.bluendo.com
> _______________________________________________
> JDev mailing list
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________


From mridulm80 at yahoo.com  Thu Apr  9 06:20:26 2009
From: mridulm80 at yahoo.com (Mridul Muralidharan)
Date: Thu, 9 Apr 2009 16:50:26 +0530 (IST)
Subject: [jdev] Using XMPP to talk to a mobile client
Message-ID: <907698.28410.qm@web95414.mail.in2.yahoo.com>




Just to mention, BOSH does not have any same client IP requirement/restriction.

And unlike tcp binding of xmpp - where session is terminated if disconnected, BOSH does handle disconnects in its design.

The only requirements would be -

a) ability of the client to connect back before the session/idle timeout.
b) BOSH gateway not going down.
c) BOSH client not going down.

b and c are mentioned - so that the session state (rid, etc) is not lost.

Regards,
Mridul



--- On Thu, 9/4/09, Jonathan Dickinson <jonathan.dickinson at k2.com> wrote:

> From: Jonathan Dickinson <jonathan.dickinson at k2.com>
> Subject: Re: [jdev] Using XMPP to talk to a mobile client
> To: "Jabber/XMPP software development list" <jdev at jabber.org>
> Date: Thursday, 9 April, 2009, 12:58 PM
> > -----Original Message-----
> > From: jdev-bounces at jabber.org
> [mailto:jdev-bounces at jabber.org]
> On
> > Behalf Of Fabio Forno
> > Sent: 08 April 2009 11:38 PM
> > To: Jabber/XMPP software development list
> > Subject: Re: [jdev] Using XMPP to talk to a mobile
> client
> > 
> > On Wed, Apr 8, 2009 at 9:26 PM, Thiranjith . <thiranjith at gmail.com>
> > wrote:
> > > Hi,
> > >
> > > Can we use XMPP to talk to a client on a mobile
> device (e.g. PDA/
> > mobile
> > > phone) that is connected to the internet using
> 3G? From what I
> > understand,
> > > phones' end-point IP changes as they move around,
> and generally they
> > are
> > > behind the network operator's (At&T, Vodafone
> etc) firewall.
> > >
> 
> IPv6 is supposed to address situations in regard to mobile
> devices. Although I am not entirely sure how well the
> technologies have been deployed. IIRC most mobile operators
> use NAT to connect clients to the internet, this means that
> the NAT will do what it can to keep your socket connections
> alive - in other words, mobile devices are less reliable
> (because they can lose signal entirely), but still
> completely viable (because the operators generally have this
> kind of stuff in mind).
> 
> My Windows Mobile phone has IPv6 and I have been able to
> access the IPv6 test website - if it works in a backwards
> country like South Africa it's gotta work in America and the
> UK!!!
>  
> > > Does the mobile client need to periodically
> notify the server about
> > its IP?
> 
> No and yes. As I said this should be handled by your
> operator's NAT: test the system and find out (connect to a
> XMPP server and go on a road trip). If it isn't you should
> definitely raise a stink.
> 
> Yes in terms that, primarily, if your public IP (i.e. one
> of your operator's IP addresses) changes chances are you are
> going to get clean disconnected. If this happens your client
> should reconnect automatically - and as a side effect of
> this the server gets your new IP.
> 
> > 
> > --
> > Fabio Forno, Ph.D.
> > Bluendo srl http://www.bluendo.com
> > jabber id: ff at jabber.bluendo.com
> > _______________________________________________
> > JDev mailing list
> > Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> > Info: http://mail.jabber.org/mailman/listinfo/jdev
> > Unsubscribe: JDev-unsubscribe at jabber.org
> > _______________________________________________
> _______________________________________________
> JDev mailing list
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________
> 


      Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/



From stpeter at stpeter.im  Thu Apr  9 09:41:22 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 09 Apr 2009 08:41:22 -0600
Subject: [jdev] Using XMPP to talk to a mobile client
In-Reply-To: <907698.28410.qm@web95414.mail.in2.yahoo.com>
References: <907698.28410.qm@web95414.mail.in2.yahoo.com>
Message-ID: <49DE0912.4030405@stpeter.im>

On 4/9/09 5:20 AM, Mridul Muralidharan wrote:
> 
> Just to mention, BOSH does not have any same client IP
> requirement/restriction.
> 
> And unlike tcp binding of xmpp - where session is terminated if
> disconnected, BOSH does handle disconnects in its design.
> 
> The only requirements would be -
> 
> a) ability of the client to connect back before the session/idle
> timeout. 

And that's part of XEP-0198. Updated version today. :)

> b) BOSH gateway not going down. 
> c) BOSH client not going down.
> 
> b and c are mentioned - so that the session state (rid, etc) is not
> lost.

Sure, if the client or server dies then state will (probably) be lost.
On the server side, people do some creative things here for high
availability / fail-over.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090409/5f740341/attachment-0002.bin>

From mridulm80 at yahoo.com  Thu Apr  9 11:33:25 2009
From: mridulm80 at yahoo.com (Mridul Muralidharan)
Date: Thu, 9 Apr 2009 22:03:25 +0530 (IST)
Subject: [jdev] Using XMPP to talk to a mobile client
Message-ID: <579761.84324.qm@web95414.mail.in2.yahoo.com>




--- On Thu, 9/4/09, Peter Saint-Andre <stpeter at stpeter.im> wrote:

> From: Peter Saint-Andre <stpeter at stpeter.im>
> Subject: Re: [jdev] Using XMPP to talk to a mobile client
> To: "Jabber/XMPP software development list" <jdev at jabber.org>
> Date: Thursday, 9 April, 2009, 8:11 PM
> On 4/9/09 5:20 AM, Mridul
> Muralidharan wrote:
> > 
> > Just to mention, BOSH does not have any same client
> IP
> > requirement/restriction.
> > 
> > And unlike tcp binding of xmpp - where session is
> terminated if
> > disconnected, BOSH does handle disconnects in its
> design..
> > 
> > The only requirements would be -
> > 
> > a) ability of the client to connect back before the
> session/idle
> > timeout. 
> 
> And that's part of XEP-0198. Updated version today. :)


Had not gone over it before, looks quite interesting - will add to my reading list ...


> 
> > b) BOSH gateway not going down. 
> > c) BOSH client not going down.
> > 
> > b and c are mentioned - so that the session state
> (rid, etc) is not
> > lost.
> 
> Sure, if the client or server dies then state will
> (probably) be lost.
> On the server side, people do some creative things here for
> high
> availability / fail-over.


Yes, I am thinking of something along those lines.
Will ping you about some queries regarding this and how it relates to stream resumption later on btw :-)

Thanks,
Mridul

> 
> Peter
> 
> -- 
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> -----Inline Attachment Follows-----
> 
> _______________________________________________
> JDev mailing list
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________
> 


      Share files, take polls, and make new friends - all under one roof. Go to http://in.promos.yahoo.com/groups/



From gnauck at ag-software.de  Thu Apr  9 12:41:48 2009
From: gnauck at ag-software.de (Alexander Gnauck)
Date: Thu, 09 Apr 2009 19:41:48 +0200
Subject: [jdev] Using XMPP to talk to a mobile client
In-Reply-To: <907698.28410.qm@web95414.mail.in2.yahoo.com>
References: <907698.28410.qm@web95414.mail.in2.yahoo.com>
Message-ID: <grlc0r$nl9$1@ger.gmane.org>

Mridul Muralidharan wrote:
> 
> 
> Just to mention, BOSH does not have any same client IP requirement/restriction.
> 
> And unlike tcp binding of xmpp - where session is terminated if disconnected, BOSH does handle disconnects in its design.
> 
> The only requirements would be -
> 
> a) ability of the client to connect back before the session/idle timeout.
> b) BOSH gateway not going down.
> c) BOSH client not going down.
> 
> b and c are mentioned - so that the session state (rid, etc) is not lost.

I have a much better experience with sockets on Mobile devices than with 
BOSH. Of course this also depends how reliable you Mobile network is, 
but in Europe its very good, and sockets works very well.

Regards,
Alex
--
Alexander Gnauck
http://www.ag-software.de
xmpp:gnauck at jabber.org



From fabio.forno at gmail.com  Thu Apr  9 14:04:48 2009
From: fabio.forno at gmail.com (Fabio Forno)
Date: Thu, 9 Apr 2009 21:04:48 +0200
Subject: [jdev] Using XMPP to talk to a mobile client
In-Reply-To: <grlc0r$nl9$1@ger.gmane.org>
References: <907698.28410.qm@web95414.mail.in2.yahoo.com>
	<grlc0r$nl9$1@ger.gmane.org>
Message-ID: <2fd53c3a0904091204r54beb404v7b331fd31a0ca227@mail.gmail.com>

On Thu, Apr 9, 2009 at 7:41 PM, Alexander Gnauck <gnauck at ag-software.de> wrote:
>
> I have a much better experience with sockets on Mobile devices than with
> BOSH. Of course this also depends how reliable you Mobile network is,
> but in Europe its very good, and sockets works very well.

Just for curisioty: bosh using the phone HTTP apis or implementing the
whole HTTP requests ?

-- 
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: ff at jabber.bluendo.com


From elghinn at free.fr  Fri Apr 10 00:05:38 2009
From: elghinn at free.fr (=?ISO-8859-15?Q?Ana=EBl_Verrier?=)
Date: Fri, 10 Apr 2009 07:05:38 +0200
Subject: [jdev] xmppony 0.1 is released!
Message-ID: <49DED3A2.1030608@free.fr>

Hi,

I'm thrilled to announce the release of xmppony 0.1.

xmppony is an XMPP library released under GNU GPLv3. It's a fork of xmpppy, 
which was in turn a fork of jabber.py.

Why a fork? Because xmpppy was almost dead in the last 2 years. Because there 
are so many things which do not suit me (like the lack of PEP 8-compliance, the 
lack of file transfer support, the coding style, the hierarchy of the code, the 
"plugin" system, the simulation of heritage, etc.).


This first release is a drop-in replacement for xmpppy, with some bugs fixed and 
file transfer added, but next releases will swap a lot more things around.


Download xmppony 0.1:
http://xmppony.last-exile.org/sources/xmppony-0.1.tar.bz2

SVN repository:
http://svn.last-exile.org/xmppony/

Browse SVN repository:
http://trac.last-exile.org/xmppony/browser

Website:
http://xmppony.last-exile.org/

Jabber room:
last-exile at muc.last-exile.org


Enjoy the release.


--
Ana?l Verrier
xmpp:elghinn at last-exile.org
GPG: 1024D/65B95D84


From norman at rasmussen.co.za  Fri Apr 10 04:46:47 2009
From: norman at rasmussen.co.za (Norman Rasmussen)
Date: Fri, 10 Apr 2009 11:46:47 +0200
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <49DED3A2.1030608@free.fr>
References: <49DED3A2.1030608@free.fr>
Message-ID: <5b698f5a0904100246t3a8f569dja688cb2f88f4d7a8@mail.gmail.com>

On Fri, Apr 10, 2009 at 7:05 AM, Ana?l Verrier <elghinn at free.fr> wrote:

> Why a fork? Because xmpppy was almost dead in the last 2 years. Because
> there
> are so many things which do not suit me (like the lack of PEP 8-compliance,
> the
> lack of file transfer support, the coding style, the hierarchy of the code,
> the
> "plugin" system, the simulation of heritage, etc.).
>

As one of the co-maintainers of xmpp.py, why is this the first time i've
heard of this?  Alexey has recently contacted me to say that he's got time
to work on xmpp.py fixing bugs, etc, and was due to release 0.5rc1 soon.

I have not yet reviewed the differences, but would you be interested in
feeding back your changes to xmpp.py?

-- 
- Norman Rasmussen
- Email: norman at rasmussen.co.za
- Home page: http://norman.rasmussen.co.za/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090410/135510b0/attachment-0002.htm>

From steve-e at h3c.de  Fri Apr 10 06:30:48 2009
From: steve-e at h3c.de (Stephan Erb)
Date: Fri, 10 Apr 2009 13:30:48 +0200
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <49DED3A2.1030608@free.fr>
References: <49DED3A2.1030608@free.fr>
Message-ID: <1239363048.5108.6.camel@localhost.localdomain>

Hey,

Gajim has forked xmpppy as well. I guess the main difference is a switch
to non-blocking sockets and the implementation of BOSH.

Maybe there is a chance here to streamline all those different efforts.

Best,
steve-e


On Fri, 2009-04-10 at 07:05 +0200, Ana?l Verrier wrote:
> Hi,
> 
> I'm thrilled to announce the release of xmppony 0.1.
> 
> xmppony is an XMPP library released under GNU GPLv3. It's a fork of xmpppy, 
> which was in turn a fork of jabber.py.
> 
> Why a fork? Because xmpppy was almost dead in the last 2 years. Because there 
> are so many things which do not suit me (like the lack of PEP 8-compliance, the 
> lack of file transfer support, the coding style, the hierarchy of the code, the 
> "plugin" system, the simulation of heritage, etc.).
> 
> 
> This first release is a drop-in replacement for xmpppy, with some bugs fixed and 
> file transfer added, but next releases will swap a lot more things around.
> 
> 
> Download xmppony 0.1:
> http://xmppony.last-exile.org/sources/xmppony-0.1.tar.bz2
> 
> SVN repository:
> http://svn.last-exile.org/xmppony/
> 
> Browse SVN repository:
> http://trac.last-exile.org/xmppony/browser
> 
> Website:
> http://xmppony.last-exile.org/
> 
> Jabber room:
> last-exile at muc.last-exile.org
> 
> 
> Enjoy the release.
> 
> 
> --
> Ana?l Verrier
> xmpp:elghinn at last-exile.org
> GPG: 1024D/65B95D84
> _______________________________________________
> JDev mailing list
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________


From asterix at lagaule.org  Fri Apr 10 06:40:13 2009
From: asterix at lagaule.org (Yann Leboulanger)
Date: Fri, 10 Apr 2009 13:40:13 +0200
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <1239363048.5108.6.camel@localhost.localdomain>
References: <49DED3A2.1030608@free.fr>
	<1239363048.5108.6.camel@localhost.localdomain>
Message-ID: <49DF301D.6070907@lagaule.org>

Stephan Erb a ?crit :
> Hey,
> 
> Gajim has forked xmpppy as well. I guess the main difference is a switch
> to non-blocking sockets and the implementation of BOSH.
> 
> Maybe there is a chance here to streamline all those different efforts.
> 
> Best,
> steve-e

That would be awsome, but I think the diff between Gajim fork and xmpppy is:

-*
+*

We re-arranged all files recently. So it will be a lot of work.


From wolf.heiner at googlemail.com  Fri Apr 10 07:26:47 2009
From: wolf.heiner at googlemail.com (Heiner Wolf)
Date: Fri, 10 Apr 2009 14:26:47 +0200
Subject: [jdev] jabber disk ?
In-Reply-To: <200903222325.n2MNPGCE017257@zogzog.maillard.mobi>
References: <200903222325.n2MNPGCE017257@zogzog.maillard.mobi>
Message-ID: <5f303cb80904100526i24671281tda272b751bfe3055@mail.gmail.com>

Hi,

Sometimes I think, that XMPP-iq-get/result does the same as
HTTP-request/response only better, because the client stays connected
and the server network does the routing including again persistent
managed connections. Beyond that, the entire RSS feed mechanism would
be much better in XMPP as pubsub. Twitter API and clients are the
worst of all. While RSS clients poll every hour, Twitter clients
HTTP-poll every minute.

To put it in other words: XMPP style two way messaging can emulate
HTTP style request/response easily. But HTTP has a hard time to
emulate two way messaging or notifications.

Would be interesting to put an XMPP transport under a Web browser and
let the XMPP server do the HTTP gateway until content servers support
XMPP natively.

Won't be easy to replace the entire infrastructure, though :-)

So, to answer your question: You might concentrate on gatewaying. Then
you can use much of the existing infrastructure. E.g. by building a
XMPP-WEBDAV gateway. WEBDAV servers provide all document management
you need for Web sites. Only thing missing to use it from the XMPP
client is a gateway. The gateway as a XMPP server component would
translate WEBDAV requests in XMPP-get/set to HTTP. Basically a
WEBDAV/XMPP to WEBDAV/HTTP gateway. What do you think?

Best
hw

On Mon, Mar 23, 2009 at 1:25 AM, Xavier Maillard <xma at gnu.org> wrote:
> Hi,
>
> I am writting a text editor with the aim to publish
> notes/articles/whatever over XMPP. I have all the basic editor
> stuff working and now has come the time to choose how to
> effectively "publish" these texts.
>
> My goal behind this, is to have access to my notes anywhere at
> anytime. I am not sure what the best method I should choose to
> store all this stuff. I know there were tries to have webdav over
> XMPP, I know there is pubsub (which has my preference) ?and
> lately I felt upon something called "jabdisk". I am looking for
> information about the later.
>
> OTOH, if you have any idea on a global storage strategy for my
> client, feel free to share them :)
>
> My main interest in writing this software is to be able to run a
> "jabber site" (aka a website) totally via XMPP and particulary a
> "XMPP wiki".
>
> Regards,
>
> ? ? ? ?Xavier
> --
> http://www.gnu.org
> http://www.april.org
> http://www.lolica.org
> _______________________________________________
> JDev mailing list
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________
>



-- 
Dr. Heiner Wolf
wolf.heiner at gmail.com
www.wolfspelz.de
www.virtual-presence.org


From simon at buddycloud.com  Fri Apr 10 08:11:11 2009
From: simon at buddycloud.com (Simon Tennant)
Date: Fri, 10 Apr 2009 15:11:11 +0200
Subject: [jdev] Using XMPP to talk to a mobile client
In-Reply-To: <grlc0r$nl9$1@ger.gmane.org>
References: <907698.28410.qm@web95414.mail.in2.yahoo.com>
	<grlc0r$nl9$1@ger.gmane.org>
Message-ID: <49DF456F.3080400@buddycloud.com>

Mobile is tricky: you fire off a stanza just as you enter a tunnel with
no coverage and your client is none the wiser as to whether the stanza
actually made it to the server. Indeed your GPRS or 3G connection may
even stay connected.

We have also had good success on the mobile by using sockets rather than
BOSH in the Buddycloud client. 

There are a couple of tricks that we used to ensure we loose no messages:

    * On mobile networks the phone client may be pushing off messages
      into a socket that has lost cellular coverage.  If you have a
      large sliding window on the TCP layer, these messages are lost.
      Twiddling your TCP stack can help keep the number of packets
      between ACKs low.
    * We have worked around these by using message archiving (XEP-0136)
      and re-requesting messages slightly before the device lost connection.
    * "warm starting".  In a bouncy environment having to pull down the
      roster, PEP and pub-sub subscriptions each time will get
      expensive.  If a session can be recovered, recover, and keep on going.

The real solution will be implementing XEP-0198: Stream Management and
managing acknowledged stanzas at the application layer. This is
something that we plan on implementing to handle the unpredictable
mobile environment.

S.

Alexander Gnauck wrote:
> Mridul Muralidharan wrote:
>   
>> Just to mention, BOSH does not have any same client IP requirement/restriction.
>>
>> And unlike tcp binding of xmpp - where session is terminated if disconnected, BOSH does handle disconnects in its design.
>>
>> The only requirements would be -
>>
>> a) ability of the client to connect back before the session/idle timeout.
>> b) BOSH gateway not going down.
>> c) BOSH client not going down.
>>
>> b and c are mentioned - so that the session state (rid, etc) is not lost.
>>     
>
> I have a much better experience with sockets on Mobile devices than with 
> BOSH. Of course this also depends how reliable you Mobile network is, 
> but in Europe its very good, and sockets works very well.
>
> Regards,
> Alex
> --
> Alexander Gnauck
> http://www.ag-software.de
> xmpp:gnauck at jabber.org
>
> _______________________________________________
> JDev mailing list
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________
>
>
>   


-- 
Simon Tennant
Buddycloud
uk: +44 20 7043 6756               de: +49 89 420 955 854  
uk: +44 78 5335 6047               de: +49 17 8545 0880
email and xmpp: simon at buddycloud.com
http://buddycloud.com



From whateley at gmail.com  Fri Apr 10 10:49:25 2009
From: whateley at gmail.com (Brendan Taylor)
Date: Fri, 10 Apr 2009 09:49:25 -0600
Subject: [jdev] jabber disk ?
In-Reply-To: <200903222325.n2MNPGCE017257@zogzog.maillard.mobi>
References: <200903222325.n2MNPGCE017257@zogzog.maillard.mobi>
Message-ID: <20090410154925.GB23928@nyarlathotep>

On Mon, Mar 23, 2009 at 12:25:16AM +0100, Xavier Maillard wrote:
> OTOH, if you have any idea on a global storage strategy for my
> client, feel free to share them :)
> 
> My main interest in writing this software is to be able to run a
> "jabber site" (aka a website) totally via XMPP and particulary a
> "XMPP wiki".

It seems to me that for this kind of project it would make sense to base
your protocol on the Atom Publishing Protocol. That gives you a pretty
well-supported representation for your pages, and as Heiner said it would
be pretty easy to imitate the HTTP requests in XMPP. It would be
interesting to see what aspects of AtomPub could be done differently
when XMPP is being used instead of HTTP.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090410/d459e71c/attachment-0002.pgp>

From elghinn at free.fr  Fri Apr 10 14:47:25 2009
From: elghinn at free.fr (=?UTF-8?B?QW5hw6tsIFZlcnJpZXI=?=)
Date: Fri, 10 Apr 2009 21:47:25 +0200
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <5b698f5a0904100246t3a8f569dja688cb2f88f4d7a8@mail.gmail.com>
References: <49DED3A2.1030608@free.fr>
	<5b698f5a0904100246t3a8f569dja688cb2f88f4d7a8@mail.gmail.com>
Message-ID: <49DFA24D.8060707@free.fr>

Norman Rasmussen a ?crit :
> On Fri, Apr 10, 2009 at 7:05 AM, Ana?l Verrier <elghinn at free.fr> wrote:
> 
>> Why a fork? Because xmpppy was almost dead in the last 2 years. Because
>> there
>> are so many things which do not suit me (like the lack of PEP 8-compliance,
>> the
>> lack of file transfer support, the coding style, the hierarchy of the code,
>> the
>> "plugin" system, the simulation of heritage, etc.).
>>
> 
> As one of the co-maintainers of xmpp.py, why is this the first time i've
> heard of this? Alexey has recently contacted me to say that he's got time
> to work on xmpp.py fixing bugs, etc, and was due to release 0.5rc1 soon.

1) I have submited a patch[1] 11 months ago.
But my patch was waiting without responses. It was not alone[2][3][4][5].

2) No clues the project was alive.
See 1).
There was only few commits in the last year, and even less if we don't count 
those which do not touch with the code (like [6] and [7])

3) We didn?t announce anything before we had something to announce.
I do not have as a practice to announce a project prematurely.

4) Misfortunate timing.
I have forked the 03/26/09 as you can see on the project timeline[8]. And 
released it today. When I have forked, Alexey had not improved yet with the 
code. Thus I had already made things before he is not put at it.

Yes, when I make the release, that made already 4-5 days that there had been of 
the activity on the repository. But I only saw it when the release was done.

But does that really change something?

5) Gr?goire Menuel proposed a patch[9] for the file transfer.
But you refused it. And whatever is the reason, at the current hour we can not 
still make a file transfer with xmpppy.

I find important to have the file transfer, in particular for a bot.

For example, Erwan Briand, the author of CodingTeam[10] and administrator of 
codingteam.net, envisages to make a robot by which one will be able to download 
the versions of the projects directly since jabber without having to go on the 
site. And it is only one example among so many others.

[1] 
http://sourceforge.net/tracker/?func=detail&aid=1961193&group_id=97081&atid=616917
[2] 
http://sourceforge.net/tracker/?func=detail&aid=1962375&group_id=97081&atid=616917
[3]
http://sourceforge.net/tracker/?func=detail&aid=1780774&group_id=97081&atid=616917
[4]
http://sourceforge.net/tracker/?func=detail&aid=1929415&group_id=97081&atid=616915
[5]
http://sourceforge.net/tracker/?func=detail&aid=1949483&group_id=97081&atid=616915

[6] 
http://xmpppy.cvs.sourceforge.net/viewvc/xmpppy/xmpppy/xmpp/protocol.py?r1=1.58&r2=1.59
[7] 
http://xmpppy.cvs.sourceforge.net/viewvc/xmpppy/xmpppy/xmpp/protocol.py?r1=1.57&r2=1.58

[8] http://trac.last-exile.org/xmppony/changeset/1

[9]
http://sourceforge.net/mailarchive/forum.php?thread_name=1122740972.42ebaaec4a799%40webmail.insa-lyon.fr&forum_name=xmpppy-devel

[10] http://codingteam.codingteam.net/


> 
> I have not yet reviewed the differences, but would you be interested in
> feeding back your changes to xmpp.py?
> 

Our fixes are and will be free software, you?ll be able to take them back if you 
want. However, I have the intention to change quite a lot of things: revamp 
simplexmp, replace debug with standard logging, get rid of fake inheritance, 
etc. Are these ground-breaking changes suitable for incorporation in xmpppy?



--
Ana?l Verrier
xmpp:elghinn at last-exile.org
GPG: 1024D/65B95D84



From norman at rasmussen.co.za  Fri Apr 10 16:23:52 2009
From: norman at rasmussen.co.za (Norman Rasmussen)
Date: Fri, 10 Apr 2009 23:23:52 +0200
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <49DFA24D.8060707@free.fr>
References: <49DED3A2.1030608@free.fr>
	<5b698f5a0904100246t3a8f569dja688cb2f88f4d7a8@mail.gmail.com>
	<49DFA24D.8060707@free.fr>
Message-ID: <5b698f5a0904101423k50f9f500m57ca90888cd76423@mail.gmail.com>

On Fri, Apr 10, 2009 at 9:47 PM, Ana?l Verrier <elghinn at free.fr> wrote:
> 1) I have submited a patch[1] 11 months ago.
> But my patch was waiting without responses. It was not alone[2][3][4][5].

Unfortunately I haven't been looking at the bug tracker on sf.net, I
haven't had time to more than apply patches sent to the mailing list.

> 2) No clues the project was alive.

the xmpp.py mailing list has about 5 or so threads per month, of which
I read each and every message.  If this thread gets anymore detailed,
I think we should perhaps redirect it to that list so that we don't
overwhelm the jdev list with our plans to rule python-xmpp
development.

> 3) We didn?t announce anything before we had something to announce.
> I do not have as a practice to announce a project prematurely.

sounds good

> 4) Misfortunate timing.
> I have forked the 03/26/09 as you can see on the project timeline[8]. And
> released it today. When I have forked, Alexey had not improved yet with the
> code. Thus I had already made things before he is not put at it.
> Yes, when I make the release, that made already 4-5 days that there had been of
> the activity on the repository. But I only saw it when the release was done.

true, misfortunate timing, yes.

> 5) Gr?goire Menuel proposed a patch[9] for the file transfer.
> But you refused it. And whatever is the reason, at the current hour we can not
> still make a file transfer with xmpppy.

wow, this was from before I started on xmpp.py.  Do you know that
there were no less than 3 requests for file transfer code in the last
6 months.  If I'd known I would have at least looked at the patch.

> Our fixes are and will be free software, you?ll be able to take them back if you
> want. However, I have the intention to change quite a lot of things: revamp
> simplexmp, replace debug with standard logging, get rid of fake inheritance,
> etc. Are these ground-breaking changes suitable for incorporation in xmpppy?

as far as I'm concerned:
 - simplexml is ugly and should be thrown away.  something like the
standard python xml.dom and xml.sax (maybe xml.dom.pulldom) would be
more than enough
 - agree on the debugging
 - not sure what you mean about the fake inheritance - do you mean the
plugging?

Much of the code of xmpp.py was written by Alexey _before_ python had
support for all this stuff in it's internal libraries.  I've had to
deal with being able to run the transports on Python 2.2.  I think
Alexey did a fantastic job with what he had to work with when he wrote
the library.  Unfortunately (as it happens to all of us), he was
unable to dedicate as much time as he would have wanted to maintaining
the library.

Moving forwards I would like to see:
 - true asynchronous code - Gajim team did this about a year ago.
They added non-blocking calls for almost everything that used to
block.  Support for asyncore would be great, because this is another
python built-in library.
 - cleaner separation of concerns - the Gajim team have started on
this.  The client should not care if the server connection is TCP or
TLS or SSL or BOSH or Magic-transport-method-5.
 - the library should continue to support client and transport
connections.  adhoc commands should get client-side (consumer) support
(currently only server-side (producer) is supported).
 - file transfer would be fantastic, would you support all 5 methods?
(si, ibb, oob, socks5, jingle)

-- 
- Norman Rasmussen
 - Email: norman at rasmussen.co.za
 - Home page: http://norman.rasmussen.co.za/


From elghinn at free.fr  Fri Apr 10 16:48:09 2009
From: elghinn at free.fr (=?ISO-8859-15?Q?Ana=EBl_Verrier?=)
Date: Fri, 10 Apr 2009 23:48:09 +0200
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <1239363048.5108.6.camel@localhost.localdomain>
References: <49DED3A2.1030608@free.fr>
	<1239363048.5108.6.camel@localhost.localdomain>
Message-ID: <49DFBE99.3090103@free.fr>

Stephan Erb a ?crit :
> Hey,
> 
> Gajim has forked xmpppy as well. I guess the main difference is a switch
> to non-blocking sockets and the implementation of BOSH.
> 
> Maybe there is a chance here to streamline all those different efforts.
> 
> Best,
> steve-e
> 
> 
Gajim uses non-blocking sockets to not have to use threads. I do not think only 
it is necessary to neglect the use of threads just to not have to be bored with, 
especially at the hour of the processors multi-cores.

Moreover as Yann said, the fork of Gajim does not really have anything any more 
to do with the xmpppy origin. So to reinstate my work in the fork of Gajim is 
impossible (of as much more than I do not intend to pass by non-blocking sockets).

Of elsewhere, it seems that the fork of Gajim is integrated now too much into 
Gajim, as if that had always done only one with Gajim.

So, that would involve large change in Gajim to set out again on the use of a 
third library.

To finish, I would say that I really intend to go in another direction that is 
currently taken by xmpppy. Although this release seems to bring nothing more 
than some corrections of bugs, a better respect of the pep8, and the file 
transfer, it is necessary to keep with the spirit that it is there to 
officialize the project.

As I said to Norman Rasmussen, I do not have any problem against the fact that 
it reinstates my modifications in xmpppy. But very sincerely I doubt that all my 
modifications are reinstated in xmpppy.

And although Alexey very recently recovered above, what says to us that he will 
have time to leave the 0.5 and to continue thereafter? Who says to us that there 
will not be another 2 year hole in the development of xmpppy?

I do not seek to blame him. He has his life. And I thank him for the work which 
he already carried out until now. Only for the reasons already evoked, I felt 
the need to fork xmpppy.

Future will tell whether my project is a mere waste of time or whether it really 
has its place. While keeping in mind that I have nothing against a future 
bringing together of the two projects, here and now I prefer coding and going ahead.

--
Ana?l Verrier
xmpp:elghinn at last-exile.org
GPG: 1024D/65B95D84


From xma at gnu.org  Sat Apr 11 13:25:02 2009
From: xma at gnu.org (Xavier Maillard)
Date: Sat, 11 Apr 2009 20:25:02 +0200
Subject: [jdev] jabber disk ?
In-Reply-To: message from Peter Saint-Andre on Mon, 06 Apr 2009 22:20:45 -0600
Message-ID: <200904111825.n3BIP2X7015823@zogzog.maillard.mobi>

Hi,

   On 3/22/09 5:25 PM, Xavier Maillard wrote:
   > 
   > I am writting a text editor with the aim to publish
   > notes/articles/whatever over XMPP. I have all the basic editor
   > stuff working and now has come the time to choose how to
   > effectively "publish" these texts.
   > 
   > My goal behind this, is to have access to my notes anywhere at
   > anytime. I am not sure what the best method I should choose to
   > store all this stuff. I know there were tries to have webdav over
   > XMPP, I know there is pubsub (which has my preference)  and
   > lately I felt upon something called "jabdisk". I am looking for
   > information about the later.
   > 
   > OTOH, if you have any idea on a global storage strategy for my
   > client, feel free to share them :)
   > 
   > My main interest in writing this software is to be able to run a
   > "jabber site" (aka a website) totally via XMPP and particulary a
   > "XMPP wiki".

   Why? Isn't that what HTTP is for?

Why ?

Some reasons:

1. for fun
2. to just have something cool to demo at my next LUG meeting
3. I am more likely to use XMPP services than any other service
(I am even connected 24/7 with my jid via my mobile)
4. I'd like to test/implement XEPs in real life

Enough ?

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org


From jonathan.dickinson at k2.com  Tue Apr 14 07:08:06 2009
From: jonathan.dickinson at k2.com (Jonathan Dickinson)
Date: Tue, 14 Apr 2009 14:08:06 +0200
Subject: [jdev] Digest URIs for XMPP
Message-ID: <A790BE8D83ECC3469047C2E344EABE61027C685F7D52@zamail01.k2workflow.com>

I am busy doing the SASL lib for my server/client (almost completely finished with DIGEST-MD5). I was just wondering what the common practice is for digest-uris with varying ports. Some people use them as follows:

Port 80:
http/www.foo.com
Port 8080:
http/www.foo.com

Where others:

Port 80:
http/www.foo.com
Port 8080:
http/www.foo.com:8080

So which one is in common use in the XMPP world?

Also where the connect server is different I would assume the following would apply (I am just confirming what I have read):

xmpp/talk.google.com/google.com

Or even:

xmpp/talk.google.com/gmail.com

Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090414/46e71d6a/attachment-0002.htm>

From stpeter at stpeter.im  Tue Apr 14 11:19:21 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 14 Apr 2009 10:19:21 -0600
Subject: [jdev] Digest URIs for XMPP
In-Reply-To: <A790BE8D83ECC3469047C2E344EABE61027C685F7D52@zamail01.k2workflow.com>
References: <A790BE8D83ECC3469047C2E344EABE61027C685F7D52@zamail01.k2workflow.com>
Message-ID: <49E4B789.40800@stpeter.im>

On 4/14/09 6:08 AM, Jonathan Dickinson wrote:
> I am busy doing the SASL lib for my server/client (almost completely
> finished with DIGEST-MD5). I was just wondering what the common practice
> is for digest-uris with varying ports. Some people use them as follows:
> 
>  
> 
> Port 80:
> 
> http/www.foo.com
> 
> Port 8080:
> 
> http/www.foo.com
> 
>  
> 
> Where others:
> 
>  
> 
> Port 80:
> 
> http/www.foo.com
> 
> Port 8080:
> 
> http/www.foo.com:8080
> 
>  
> 
> So which one is in common use in the XMPP world?

Isn't this what SRV records are for?

> Also where the connect server is different I would assume the following
> would apply (I am just confirming what I have read):
> 
>  
> 
> xmpp/talk.google.com/google.com
> 
>  
> 
> Or even:
> 
>  
> 
> xmpp/talk.google.com/gmail.com

As you know from RFC 2831, the format is:

serv-type "/" host [ "/" serv-name ]

The serv-type is always xmpp for us.

The host is the machine you connect to (or discover via SRV).

The serv-name is the name used by the client to discover the machine.

In the case of Google Talk, you look up gmail.com (or googlemail.com or
whatever) and discover things like this:

$ dig +short -t SRV _xmpp-client._tcp.gmail.com
20 0 5222 talk4.l.google.com.
5 0 5222 talk.l.google.com.
20 0 5222 talk1.l.google.com.
20 0 5222 talk2.l.google.com.
20 0 5222 talk3.l.google.com.

So I think that the resulting digest-uri would be of this form:

xmpp/talk.l.google.com/gmail.com

But I freely admit that this might be subject to interpretation, as so
many things are when it comes to the DIGEST-MD5 SASL mechanism. :(

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090414/8a53d1c3/attachment-0002.bin>

From stpeter at stpeter.im  Tue Apr 14 17:09:55 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 14 Apr 2009 16:09:55 -0600
Subject: [jdev] MXM #2
Message-ID: <49E509B3.2090308@stpeter.im>

On March 12 and again today, we held a "Monthly XMPP Meeting":

http://logs.jabber.org/jdev at conference.jabber.org/2009-03-12.html#15:01:15

http://logs.jabber.org/jdev at conference.jabber.org/2009-04-14.html#14:06:45

I know it's a bit backwards, but I'm going to report on today's meeting
first because it's fresh in my mind (and sorry about not yet publishing
minutes from the first meeting). There was no set agenda, but we talked
about the following topics:

1. Last Call for XEP-0232 (Software Information)

http://xmpp.org/extensions/xep-0232.html

http://logs.jabber.org/jdev at conference.jabber.org/2009-04-14.html#14:10:41

Points:

- Is this a misuse of service discovery?

- Will this make entity capability caches less useful because they will
be too large to search easily?

- Does it make more sense to publish this information via PEP using the
XEP-0092 format?

The XMPP Council will vote on XEP-0232 at its next meeting (April 22).
More feedback is welcome before then.

2. Last Call for XEP-0237 (Roster Versioning)

http://xmpp.org/extensions/xep-0237.html

http://logs.jabber.org/jdev at conference.jabber.org/2009-04-14.html#14:23:19

General agreement that this is in good shape. There are still a few edge
cases to figure out, especially the empty roster case.

3. Last Calls for the core Jingle specs

http://logs.jabber.org/jdev at conference.jabber.org/2009-04-14.html#14:29:52

No real discussion here. Most people seemed to think that these are
ready for Draft.

4. Pubsub/PEP implementations

http://logs.jabber.org/jdev at conference.jabber.org/2009-04-14.html#14:37:41

Consensus that we need more interop testing among idavoll, ejabberd,
Openfire, Tigase, etc. Perhaps make this a focus at the next XMPP Summit.

5. XEP-0198 (Stream Management)

http://xmpp.org/extensions/xep-0198.html

http://logs.jabber.org/jdev at conference.jabber.org/2009-04-14.html#14:53:43

People like this. Let's go forth and implement. :)

6. Bidirectional s2s

http://logs.jabber.org/jdev at conference.jabber.org/2009-04-14.html#15:00:34

We decided that we need a dedicated discussion session about s2s fixes
and improvements (dialback, multiplexing domains over a given stream via
TLS/SASL/dialback/whatever, etc.). We agreed to make that the focus of
the next Monthly XMPP Meeting, tentatively scheduled for May 5.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090414/696ff0c2/attachment-0002.bin>

From Kurt.Zeilenga at Isode.com  Tue Apr 14 22:30:36 2009
From: Kurt.Zeilenga at Isode.com (Kurt Zeilenga)
Date: Tue, 14 Apr 2009 20:30:36 -0700
Subject: [jdev] Digest URIs for XMPP
In-Reply-To: <49E4B789.40800@stpeter.im>
References: <A790BE8D83ECC3469047C2E344EABE61027C685F7D52@zamail01.k2workflow.com>
	<49E4B789.40800@stpeter.im>
Message-ID: <452495EA-3CB7-40BD-A773-B4B144397FC9@Isode.com>

I think clients ought to simply assert xmpp/host where host is  
whatever string the user specified to connect to.

But more importantly is what should the server do.  RFC 2831 says:
    Servers SHOULD check that the supplied value is correct. This will
    detect accidental connection to the incorrect server. It is also so
    that clients will be trained to provide values that will work with
    implementations that use a shared back-end authentication service
    that can provide server authentication.

I suggest instead:
    Servers SHOULD ignore that the supplied value.  The check
    was intended to detect that client did not accidentally
    connect to the incorrect server.  Performing the check will far more
    likely lead to disconnecting of clients which did connect to the
    correct server than disconnecting clients which accidentally  
connected
    to an incorrect server.

Such checks tend to make the application services brittle.   (Consider  
the implications of forward and reverse NAT devices, transparent (to  
the client and server) tunneling, etc.)

-- Kurt



From dave at cridland.net  Wed Apr 15 04:54:49 2009
From: dave at cridland.net (Dave Cridland)
Date: Wed, 15 Apr 2009 10:54:49 +0100
Subject: [jdev] [Standards] MXM #2
In-Reply-To: <49E509B3.2090308@stpeter.im>
References: <49E509B3.2090308@stpeter.im>
Message-ID: <7088.1239789289.390264@puncture>

On Tue Apr 14 23:09:55 2009, Peter Saint-Andre wrote:
> The XMPP Council will vote on XEP-0232 at its next meeting (April  
> 22).
> More feedback is welcome before then.
> 
> 
As usual, you're welcome to turn up to the Council meetings, and  
express your views there. (But for the next meeting, you'll need to  
bring cake.)

> We decided that we need a dedicated discussion session about s2s  
> fixes
> and improvements (dialback, multiplexing domains over a given  
> stream via
> TLS/SASL/dialback/whatever, etc.). We agreed to make that the focus  
> of
> the next Monthly XMPP Meeting, tentatively scheduled for May 5.

Matthew Wild and I have agreed to write "something" up in terms of a  
strawman proposal we can batter about.

Feel free to write one too - I'll endeavour to send something to the  
list before then.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade


From jonathan.dickinson at k2.com  Wed Apr 15 07:52:13 2009
From: jonathan.dickinson at k2.com (Jonathan Dickinson)
Date: Wed, 15 Apr 2009 14:52:13 +0200
Subject: [jdev] SASL (again)
Message-ID: <A790BE8D83ECC3469047C2E344EABE61027CE3C683B4@zamail01.k2workflow.com>

Hi All,

RFC 4616 implies that it is possible to store a digest for CRAM-MD5 in the database (just above 3. Pseudo-Code). From what I can tell you need to store a plain-text password (at best the XORed passwords, which is pointless).

A CRAM digest is created as follows:

MD5(
   (K XOR opad),
   MD5(
      (K XOR ipad),
      timestamp
      )
   )

Where 'timestamp' is variant ("<" num "." num "@" domain ">"). Am I missing some mathematical nuance, or is RFC 4616 misleading?

Jonathan





From dave at cridland.net  Wed Apr 15 09:57:53 2009
From: dave at cridland.net (Dave Cridland)
Date: Wed, 15 Apr 2009 15:57:53 +0100
Subject: [jdev] SASL (again)
In-Reply-To: <A790BE8D83ECC3469047C2E344EABE61027CE3C683B4@zamail01.k2workflow.com>
References: <A790BE8D83ECC3469047C2E344EABE61027CE3C683B4@zamail01.k2workflow.com>
Message-ID: <7088.1239807473.358000@puncture>

On Wed Apr 15 13:52:13 2009, Jonathan Dickinson wrote:
> Hi All,
> 
> RFC 4616 implies that it is possible to store a digest for CRAM-MD5  
> in the database (just above 3. Pseudo-Code). From what I can tell  
> you need to store a plain-text password (at best the XORed  
> passwords, which is pointless).
> 
> 
In all practical senses, yes, but it's possible to store a  
digest-like entity.

> A CRAM digest is created as follows:
> 
> MD5(
>    (K XOR opad),
>    MD5(
>       (K XOR ipad),
>       timestamp
>       )
>    )

Where, in turn, K is derived from, in C-like pseudocode:

K = (strlen(password) > L) ? MD5(password) : password + ('\0' * (L -  
strlen(password)))
Where L is the block length of the hash algorithm, or 128 bits in the  
case of MD5.

So K might be reasonable stuff, or it might be the password.

But that's not what CRAM-MD5 suggests storing - they suggest storing  
the intemediate hash states - effectively an MD5 internal array pair  
pre-primed with (K ^ opad) and (K ^ ipad). This is considerably more  
secure than "just a XOR", as K is at least one block-size, and  
therefore it's roughly the same, I think, as an MD5 to extract the  
password, which is to say it requires a brute-force attack, made  
harder because the combination of the two hashes means that you need  
to find a solution to both.

Still, in general, you just call an HMAC-MD5 function in some  
library, and, in rare cases, you write the HMAC wrapper over a stock  
MD5 - either way, the best you have is the XOR products, which aren't  
nearly as good unless your users really like long passwords.

Moreover, by doing this, you're forced into storing a seperate secret  
for DIGEST-MD5, so in most cases, server implementors have two modes  
- storing plaintext passwords, for flexiblility in mechanisms, and  
storing hashed passwords, which essentially restricts to PLAIN and -  
hopefully soon - SCRAM.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade


From elghinn at free.fr  Wed Apr 15 19:08:18 2009
From: elghinn at free.fr (=?UTF-8?B?QW5hw6tsIFZlcnJpZXI=?=)
Date: Thu, 16 Apr 2009 02:08:18 +0200
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <5b698f5a0904101423k50f9f500m57ca90888cd76423@mail.gmail.com>
References: <49DED3A2.1030608@free.fr>	<5b698f5a0904100246t3a8f569dja688cb2f88f4d7a8@mail.gmail.com>	<49DFA24D.8060707@free.fr>
	<5b698f5a0904101423k50f9f500m57ca90888cd76423@mail.gmail.com>
Message-ID: <49E676F2.3030804@free.fr>

Norman Rasmussen a ?crit :
>> Our fixes are and will be free software, you?ll be able to take them back if you
>> want. However, I have the intention to change quite a lot of things: revamp
>> simplexmp, replace debug with standard logging, get rid of fake inheritance,
>> etc. Are these ground-breaking changes suitable for incorporation in xmpppy?
> 
> as far as I'm concerned:
>  - simplexml is ugly and should be thrown away.  something like the
> standard python xml.dom and xml.sax (maybe xml.dom.pulldom) would be
> more than enough
I don't think that removing simplexml would be a good thing. simplexml is simple
(Captain Obvious agrees), and having a simple API to make Python objets from an
XML stream (thanks to expat) and serialize them back (thanks to __str__) seems
useful to me. I prefer cleaning simplexml than using DOM. I think we don?t need
such a complicated interface to handle stanzas.

>  - not sure what you mean about the fake inheritance - do you mean the
> plugging?
Yes, the plugin system and the horror[1] in client.py (CommonClient is derivated
in Client and Component, but its contructor does different things according to
the one call it (Client.__init__ or Component.__init__)). And other stuff like
this one.

[1] http://trac.last-exile.org/xmppony/browser/trunk/xmppony/client.py?rev=30#L119

> 
> Much of the code of xmpp.py was written by Alexey _before_ python had
> support for all this stuff in it's internal libraries.  I've had to
> deal with being able to run the transports on Python 2.2.  I think
> Alexey did a fantastic job with what he had to work with when he wrote
> the library.  Unfortunately (as it happens to all of us), he was
> unable to dedicate as much time as he would have wanted to maintaining
> the library.
> 
As I already said to steve-e, I thank him for his job and I don't blame him: he
has his life.

> Moving forwards I would like to see:
>  - true asynchronous code - Gajim team did this about a year ago.
> They added non-blocking calls for almost everything that used to
> block.  Support for asyncore would be great, because this is another
> python built-in library.
I don't understand why people do not like threads :'(
threading is a standard Python module too.

>  - cleaner separation of concerns - the Gajim team have started on
> this.  The client should not care if the server connection is TCP or
> TLS or SSL or BOSH or Magic-transport-method-5.
That sounds good.

I want Magic-transport-method-5 \o/

>  - the library should continue to support client and transport
> connections.  adhoc commands should get client-side (consumer) support
> (currently only server-side (producer) is supported).
Adhoc commands, pep, and other cool stuff are on my roadmap for v0.3.


>  - file transfer would be fantastic, would you support all 5 methods?
> (si, ibb, oob, socks5, jingle)
> 
For now, xmppony supports si, socks5 and ibb. With emacs-jabber, I can already
send and receive files from a bot based on xmppony.
Jingle support would be great, but I didn't plan to touch it now (except if
someone sends me a patch).


As I said in previous mail, for v0.2, I plan to revamp simplexml, replace debug
with standard logging and get rid of fake inheritance. But I also take a look to
rfcs and xeps. Because they evolved since the code was written. For example, I
found 2 problems in omega's patch (which was written 4-5 years ago). I also plan
to make some unit tests.

The base must be cleanest possible before going further!


-- 
Ana?l Verrier
xmpp:elghinn at last-exile.org
GPG: 1024D/65B95D84





From asterix at lagaule.org  Thu Apr 16 02:21:32 2009
From: asterix at lagaule.org (Yann Leboulanger)
Date: Thu, 16 Apr 2009 09:21:32 +0200
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <49E676F2.3030804@free.fr>
References: <49DED3A2.1030608@free.fr>	<5b698f5a0904100246t3a8f569dja688cb2f88f4d7a8@mail.gmail.com>	<49DFA24D.8060707@free.fr>	<5b698f5a0904101423k50f9f500m57ca90888cd76423@mail.gmail.com>
	<49E676F2.3030804@free.fr>
Message-ID: <49E6DC7C.6080209@lagaule.org>

Ana?l Verrier wrote:

> As I said in previous mail, for v0.2, I plan to revamp simplexml, replace debug
> with standard logging and get rid of fake inheritance. But I also take a look to
> rfcs and xeps. Because they evolved since the code was written. For example, I
> found 2 problems in omega's patch (which was written 4-5 years ago). I also plan
> to make some unit tests.

We already have logging system based on logging module in Gajim
We have unittest for some xmpppy things. Have a look at test folder.
What about zeroconf?

Really sad all that work is duplicated :/

-- 
Yann


From norman at rasmussen.co.za  Thu Apr 16 03:12:34 2009
From: norman at rasmussen.co.za (Norman Rasmussen)
Date: Thu, 16 Apr 2009 10:12:34 +0200
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <49E676F2.3030804@free.fr>
References: <49DED3A2.1030608@free.fr>
	<5b698f5a0904100246t3a8f569dja688cb2f88f4d7a8@mail.gmail.com>
	<49DFA24D.8060707@free.fr>
	<5b698f5a0904101423k50f9f500m57ca90888cd76423@mail.gmail.com>
	<49E676F2.3030804@free.fr>
Message-ID: <5b698f5a0904160112k76801109k50c6d7f7e2394c41@mail.gmail.com>

On Thu, Apr 16, 2009 at 2:08 AM, Ana?l Verrier <elghinn at free.fr> wrote:
>> ?- true asynchronous code - Gajim team did this about a year ago.
>> They added non-blocking calls for almost everything that used to
>> block. ?Support for asyncore would be great, because this is another
>> python built-in library.
> I don't understand why people do not like threads :'(
> threading is a standard Python module too.

because you can't spin off one thread for each connection on a server :-)

(on a client it's reasonable, because you may only have 5 to 10
threads, but one a server with 100+ threads, it starts to go haywire)

-- 
- Norman Rasmussen
 - Email: norman at rasmussen.co.za
 - Home page: http://norman.rasmussen.co.za/


From dave at cridland.net  Thu Apr 16 03:43:38 2009
From: dave at cridland.net (Dave Cridland)
Date: Thu, 16 Apr 2009 09:43:38 +0100
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <49DFBE99.3090103@free.fr>
References: <49DED3A2.1030608@free.fr>
	<1239363048.5108.6.camel@localhost.localdomain>
	<49DFBE99.3090103@free.fr>
Message-ID: <12297.1239871418.665567@puncture>

On Fri Apr 10 22:48:09 2009, Ana?l Verrier wrote:
> Gajim uses non-blocking sockets to not have to use threads. I do  
> not think only
> it is necessary to neglect the use of threads just to not have to  
> be bored with,
> especially at the hour of the processors multi-cores.

I think you want to be careful about what you're implying, there.  
Gajim's architecture - using a single non-blocking thread - is  
perfectly fine, as you certainly don't want or need multithreading  
there.

You do need threads for high-volume systems, but you want them  
scaling by core, not by connection.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade


From dmeyer at tzi.de  Thu Apr 16 07:04:43 2009
From: dmeyer at tzi.de (Dirk Meyer)
Date: Thu, 16 Apr 2009 14:04:43 +0200
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <49E676F2.3030804@free.fr> (=?iso-8859-1?Q?=22Ana=EBl?=
	Verrier"'s message of "Thu\, 16 Apr 2009 02\:08\:18 +0200")
References: <49DED3A2.1030608@free.fr>
	<5b698f5a0904100246t3a8f569dja688cb2f88f4d7a8@mail.gmail.com>
	<49DFA24D.8060707@free.fr>
	<5b698f5a0904101423k50f9f500m57ca90888cd76423@mail.gmail.com>
	<49E676F2.3030804@free.fr>
Message-ID: <87skk8x0ro.fsf@phex.sachmittel.de>

Ana?l Verrier wrote:
> I don't understand why people do not like threads :'(

Because you get race conditions

>From one of your other mails:
> Gajim uses non-blocking sockets to not have to use threads. I do not
> think only it is necessary to neglect the use of threads just to not
> have to be bored with, especially at the hour of the processors
> multi-cores.

Python does not benefit from multi-cores when using threads. The
interpreter lock makes multi-core useless unless you are in a C module
and release the lock. Gajim will not benefit from threads at all.


Dirk

-- 
Those that make the rules don't play the game!


From dave at cridland.net  Thu Apr 16 07:17:46 2009
From: dave at cridland.net (Dave Cridland)
Date: Thu, 16 Apr 2009 13:17:46 +0100
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <87skk8x0ro.fsf@phex.sachmittel.de>
References: <49DED3A2.1030608@free.fr>
	<5b698f5a0904100246t3a8f569dja688cb2f88f4d7a8@mail.gmail.com>
	<49DFA24D.8060707@free.fr>
	<5b698f5a0904101423k50f9f500m57ca90888cd76423@mail.gmail.com>
	<49E676F2.3030804@free.fr> <87skk8x0ro.fsf@phex.sachmittel.de>
Message-ID: <12297.1239884266.048964@puncture>

On Thu Apr 16 13:04:43 2009, Dirk Meyer wrote:
> Ana?l Verrier wrote:
> > I don't understand why people do not like threads :'(
> 
> Because you get race conditions
> 
> 
And if you're in a race, and you have a loose thread, it can get  
caught on a bush an unravel your whole jumper.

Sorry, realised I hadn't made any bad jokes on this list in ages,  
although that does look like a disturbingly good analogy.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade


From merwok at netwok.org  Thu Apr 16 21:29:15 2009
From: merwok at netwok.org (=?utf-8?Q? =C3=89ric=20Araujo =20)
Date: Fri, 17 Apr 2009 04:29:15 +0200
Subject: [jdev] xmppony 0.1 is released!
Message-ID: <54216.1239935355@netwok.org>

Hello jdev


Let me first introduce myself, as a newcomer on this list. I am a Python
programmer and Jabber enthusiast. I hang around on some of the same chatrooms
as elghinn. I?ve known of the fork project since its beginning, made some minor
patches, and found the name. Note that my understanding of XMPP is incomplete:
I?ve read user documentation and some presentations about the protocol, but not
the specifications, therefore I cannot debate stuff related to the protocol
itself, but I do have strong opinions about Python code and some requests about
the features and API of the library. I speak on my own behalf, with bits from
discussions with elghinn.


[Yann Leboulanger]
> We already have logging system based on logging module in Gajim
I wanted to do this part of the fork, so I?ll make sure to look at Gajim?s
solution first. Thanks.

> We have unittest for some xmpppy things. Have a look at test folder.
I?m sure elghinn will look at that, especially since Gajim is under GPLv3 too.

> What about zeroconf?
Depends on the aims of xmppony. If it should be the Python library for clients,
bots and scripts, it would be in. If it aims at being the Python library for
scripts and bots (elghinn?s original idea), that would be overkill. elghinn
won?t write zeroconf support, but patches will probably be accepted. Or perhaps
not, if there?s no long-term support with the patches.

> Really sad all that work is duplicated :/
Well, this discussion is a starting point for cooperation.


[Norman Rasmussen]
>> I don't understand why people do not like threads :'(
> because you can't spin off one thread for each connection on a server :-)
elghinn does not intend to use Python for a server, seeing there are really
good C/C++ libraries out there.


[Dirk Meyer]
>> I don't understand why people do not like threads :'(
> Because you get race conditions
We believe locks can prevent them.


[Dave Cridland]
>> Gajim uses non-blocking sockets to not have to use threads. I do not think
>> only it is necessary to neglect the use of threads just to not have to be
>> bored with, especially at the hour of the processors multi-cores.
> I think you want to be careful about what you're implying, there. Gajim's
> architecture - using a single non-blocking thread - is  perfectly fine, as
> you certainly don't want or need multithreading there.
>
> You do need threads for high-volume systems, but you want them scaling by
> core, not by connection.
I?m not well-versed enough in parallel processing to make an answer here.

And thank you for the joke :]


Cheers,

?ric Araujo



From stpeter at stpeter.im  Tue Apr 21 17:27:26 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 21 Apr 2009 16:27:26 -0600
Subject: [jdev] gaming@xmpp.org
Message-ID: <49EE484E.6050105@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've created a new list for discussions related to gaming applications
of XMPP technologies. Subscribe here:

http://mail.jabber.org/mailman/listinfo/gaming

mailto:gaming-subscribe at xmpp.org

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknuSE4ACgkQNL8k5A2w/vzovwCcCwZR92qZi5MgTFfJoDlslHVu
ZmgAnR0hMr8bH3hBL7LEZI3ShR/WzT3j
=9IxI
-----END PGP SIGNATURE-----


From bf_lists at brainlounge.de  Wed Apr 22 03:36:57 2009
From: bf_lists at brainlounge.de (Bernd Fondermann)
Date: Wed, 22 Apr 2009 10:36:57 +0200
Subject: [jdev] [ANN] Apache Vysper and GSoC project
Message-ID: <49EED729.9040507@brainlounge.de>

Hi,

Apache Vysper (pronounce 'whisper', source[1], docs[2]) is an
ASL-licensed[4] open source XMPP implementation in Java currently under
development at the Apache Software Foundation.

After some years at Apache Labs, Vysper is now a sub-project of Apache
MINA[3] and development will hopefully take up speed there.

Vysper has seen no release yet, is not ready for production, and docs
are still sparse.

Additionally, I'm happy to announce that we can welcome Michael Jakl as
a Google Summer of Code student this year. He will implement PubSub for
Vysper. So XMPP is not completely lost on SoC :-)

The ASF is an open community not very different in mindset from the XSF.
So everybody here is invited to use, participate and contribute to
Apache Vysper.

Thanks for listening,

  Bernd

XMPP: berndf at jabber.org
MAIL: berndf at apache.org

[1] http://svn.apache.org/repos/asf/mina/sandbox/vysper
[2] http://cwiki.apache.org/confluence/display/labs/vysper
[3] http://mina.apache.org
[4] http://svn.apache.org/repos/asf/mina/sandbox/vysper/LICENSE.txt





From sh at defuze.org  Wed Apr 22 05:40:02 2009
From: sh at defuze.org (Sylvain Hellegouarch)
Date: Wed, 22 Apr 2009 12:40:02 +0200
Subject: [jdev] [ANN] Apache Vysper and GSoC project
In-Reply-To: <49EED729.9040507@brainlounge.de>
References: <49EED729.9040507@brainlounge.de>
Message-ID: <49EEF402.3080604@defuze.org>

Bernd Fondermann a ?crit :
> Hi,
>
> Apache Vysper (pronounce 'whisper', source[1], docs[2]) is an
> ASL-licensed[4] open source XMPP implementation in Java currently under
> development at the Apache Software Foundation.
>
> After some years at Apache Labs, Vysper is now a sub-project of Apache
> MINA[3] and development will hopefully take up speed there.
>
> Vysper has seen no release yet, is not ready for production, and docs
> are still sparse.
>
> Additionally, I'm happy to announce that we can welcome Michael Jakl as
> a Google Summer of Code student this year. He will implement PubSub for
> Vysper. So XMPP is not completely lost on SoC :-)
>
> The ASF is an open community not very different in mindset from the XSF.
> So everybody here is invited to use, participate and contribute to
> Apache Vysper.
>
> Thanks for listening,
>
>   Bernd
>
> XMPP: berndf at jabber.org
> MAIL: berndf at apache.org
>
> [1] http://svn.apache.org/repos/asf/mina/sandbox/vysper
> [2] http://cwiki.apache.org/confluence/display/labs/vysper
> [3] http://mina.apache.org
> [4] http://svn.apache.org/repos/asf/mina/sandbox/vysper/LICENSE.txt
>
>   

Nice.

However, how many XMPP server written in Java do we need? Why not 
helping on Tigase for instance? I'm puzzled since XMPP servers are hard 
to write, we had OpenFire then Tigase now Vysper.

Anyhow, all the best for it :)

- Sylvain


From bf_lists at brainlounge.de  Wed Apr 22 06:12:28 2009
From: bf_lists at brainlounge.de (Bernd Fondermann)
Date: Wed, 22 Apr 2009 13:12:28 +0200
Subject: [jdev] [ANN] Apache Vysper and GSoC project
In-Reply-To: <49EEF402.3080604@defuze.org>
References: <49EED729.9040507@brainlounge.de> <49EEF402.3080604@defuze.org>
Message-ID: <49EEFB9C.7070402@brainlounge.de>

Sylvain Hellegouarch wrote:
> Bernd Fondermann a ?crit :
>> Hi,
>>
>> Apache Vysper (pronounce 'whisper', source[1], docs[2]) is an
>> ASL-licensed[4] open source XMPP implementation in Java currently under
>> development at the Apache Software Foundation.
>>
>> After some years at Apache Labs, Vysper is now a sub-project of Apache
>> MINA[3] and development will hopefully take up speed there.
>>
>> Vysper has seen no release yet, is not ready for production, and docs
>> are still sparse.
>>
>> Additionally, I'm happy to announce that we can welcome Michael Jakl as
>> a Google Summer of Code student this year. He will implement PubSub for
>> Vysper. So XMPP is not completely lost on SoC :-)
>>
>> The ASF is an open community not very different in mindset from the XSF.
>> So everybody here is invited to use, participate and contribute to
>> Apache Vysper.
>>
>> Thanks for listening,
>>
>>   Bernd
>>
>> XMPP: berndf at jabber.org
>> MAIL: berndf at apache.org
>>
>> [1] http://svn.apache.org/repos/asf/mina/sandbox/vysper
>> [2] http://cwiki.apache.org/confluence/display/labs/vysper
>> [3] http://mina.apache.org
>> [4] http://svn.apache.org/repos/asf/mina/sandbox/vysper/LICENSE.txt
>>
>>   
> 
> Nice.
> 
> However, how many XMPP server written in Java do we need? Why not
> helping on Tigase for instance? I'm puzzled since XMPP servers are hard
> to write, we had OpenFire then Tigase now Vysper.

Thanks for the question, it is very valid.
You are right, the XMPP server ecosystem is very diverse (in terms of
implementation language). Yet, most of the implementations are GPL'ed.

I prefer BSD/ASL-licensed software - not neccessarily as a user, but
when writing code. (The GPL is a very good and a strong license, and so
are BSD-type licenses. Every class has its weaknesses and strengths. I
have not the slightest interest in discussion superiority of any of
them.) It's intended providing a choice here for XMPP server users.
Implementation-wise we are still far away from being that choice.

You could still argue that I should have tried to persuaed some
implementation to move to ASL, but (if they'd had agreed) that would
have taken all the fun of writing a XMPP server from scratch.

> Anyhow, all the best for it :)

Thanks! :-)

  Bernd


From sh at defuze.org  Wed Apr 22 06:30:51 2009
From: sh at defuze.org (Sylvain Hellegouarch)
Date: Wed, 22 Apr 2009 13:30:51 +0200 (CEST)
Subject: [jdev] [ANN] Apache Vysper and GSoC project
In-Reply-To: <49EEFB9C.7070402@brainlounge.de>
References: <49EED729.9040507@brainlounge.de> <49EEF402.3080604@defuze.org>
	<49EEFB9C.7070402@brainlounge.de>
Message-ID: <53147.193.253.216.132.1240399851.squirrel@mail1.webfaction.com>


> I prefer BSD/ASL-licensed software - not neccessarily as a user, but
> when writing code. (The GPL is a very good and a strong license, and so
> are BSD-type licenses. Every class has its weaknesses and strengths. I
> have not the slightest interest in discussion superiority of any of
> them.) It's intended providing a choice here for XMPP server users.
> Implementation-wise we are still far away from being that choice.

That's a valid point and I share your views on the licensing subject.

>
> You could still argue that I should have tried to persuaed some
> implementation to move to ASL, but (if they'd had agreed) that would
> have taken all the fun of writing a XMPP server from scratch.

True. Like I wrote my own XMPP lib in Python when I could've tried to help
an existing one. Fun is the first motivational aspect of most OSS projects
:)

- Sylvain


-- 
Sylvain Hellegouarch
http://www.defuze.org


From jonathan.dickinson at k2.com  Thu Apr 23 04:02:22 2009
From: jonathan.dickinson at k2.com (Jonathan Dickinson)
Date: Thu, 23 Apr 2009 11:02:22 +0200
Subject: [jdev] [ANN] Apache Vysper and GSoC project
In-Reply-To: <49EEF402.3080604@defuze.org>
References: <49EED729.9040507@brainlounge.de> <49EEF402.3080604@defuze.org>
Message-ID: <A790BE8D83ECC3469047C2E344EABE61027E35F7C3D6@zamail01.k2workflow.com>

> -----Original Message-----
> From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] On
> Behalf Of Sylvain Hellegouarch
> Sent: 22 April 2009 12:40 PM
> To: Jabber/XMPP software development list
> Subject: Re: [jdev] [ANN] Apache Vysper and GSoC project
> 
> [...] I'm puzzled since XMPP servers are hard
> to write, we had OpenFire then Tigase now Vysper.
> 

Amen. However, writing an XMPP server is a pleasure at the same time! It will be interesting to see what they come up with (it will be pretty hard to follow in Tigase' steps).

> Anyhow, all the best for it :)
> 
> - Sylvain
> _______________________________________________
> JDev mailing list
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________


From will at netmindz.net  Wed Apr 29 15:11:06 2009
From: will at netmindz.net (Will Tatam)
Date: Wed, 29 Apr 2009 21:11:06 +0100
Subject: [jdev] Flash conference
Message-ID: <49F8B45A.3030200@netmindz.net>

Anyone recommend any pre-existing flash xmpp conference clients ? I'm 
looking at add a flash chatroom to a site

I know I could build by own using XIFF but as i've not done and flash in 
about 3 years a pre-existing one would be preferable

Will


From dave at cridland.net  Wed Apr 29 15:20:36 2009
From: dave at cridland.net (Dave Cridland)
Date: Wed, 29 Apr 2009 21:20:36 +0100
Subject: [jdev] Flash conference
In-Reply-To: <49F8B45A.3030200@netmindz.net>
References: <49F8B45A.3030200@netmindz.net>
Message-ID: <15169.1241036436.511912@puncture>

On Wed Apr 29 21:11:06 2009, Will Tatam wrote:
> Anyone recommend any pre-existing flash xmpp conference clients ?  
> I'm looking at add a flash chatroom to a site
> 
> I know I could build by own using XIFF but as i've not done and  
> flash in about 3 years a pre-existing one would be preferable

Why Flash? Will Speeqe not do?

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade


From nathanfritz at gmail.com  Wed Apr 29 16:22:22 2009
From: nathanfritz at gmail.com (Nathan Fritz)
Date: Wed, 29 Apr 2009 14:22:22 -0700
Subject: [jdev] Flash conference
In-Reply-To: <15169.1241036436.511912@puncture>
References: <49F8B45A.3030200@netmindz.net> <15169.1241036436.511912@puncture>
Message-ID: <182eea400904291422k3ebed760o597074fec6db1983@mail.gmail.com>

On Wed, Apr 29, 2009 at 1:20 PM, Dave Cridland <dave at cridland.net> wrote:

> On Wed Apr 29 21:11:06 2009, Will Tatam wrote:
>
>> Anyone recommend any pre-existing flash xmpp conference clients ? I'm
>> looking at add a flash chatroom to a site
>
>
>> I know I could build by own using XIFF but as i've not done and flash in
>> about 3 years a pre-existing one would be preferable
>>
>
My Flash lib includes a MUC example.  Seesmic-AS3-XMPP aka TwhiX.


>
> Why Flash? Will Speeqe not do?
>
> Dave.
> --
> Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net<xmpp%3Adwd at dave.cridland.net>
>  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
>  - http://dave.cridland.net/
> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
>
> _______________________________________________
> JDev mailing list
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090429/783d9780/attachment-0002.htm>

From will at netmindz.net  Wed Apr 29 17:04:51 2009
From: will at netmindz.net (Will Tatam)
Date: Wed, 29 Apr 2009 23:04:51 +0100
Subject: [jdev] (no subject)
In-Reply-To: <15169.1241036436.511912@puncture>
References: <49F8B45A.3030200@netmindz.net> <15169.1241036436.511912@puncture>
Message-ID: <49F8CF03.10007@netmindz.net>

On 29/04/09 21:20, Dave Cridland wrote:
> On Wed Apr 29 21:11:06 2009, Will Tatam wrote:
>> Anyone recommend any pre-existing flash xmpp conference clients ? I'm
>> looking at add a flash chatroom to a site
>>
>> I know I could build by own using XIFF but as i've not done and flash
>> in about 3 years a pre-existing one would be preferable
>
> Why Flash? Will Speeqe not do?
>
> Dave.

It has a whole stack of server dependencies, flash would just be client 
side plus XMPP server of choice, not python, django, postgresql ... etc


From koski.tuomas at gmail.com  Wed Apr 29 17:41:26 2009
From: koski.tuomas at gmail.com (Tuomas Koski)
Date: Thu, 30 Apr 2009 00:41:26 +0200
Subject: [jdev] Example PubSub -service to publish BBC World News
Message-ID: <1d142be30904291541p63221e61kd621e3718334f972@mail.gmail.com>

Hi guys and gals,

I'm kind of new to XMPP techniques and I'm a person who only learns by
"doing it my self" so:

I did a example PubSub service that publishes all the BBC World News
as they are published by BBC. There are 2 ways to subscribe to the
service:

1) add bbc-news at xmpp.lobstermonster.org to your XMPP roster
 OR
2) find "bbc_news" -node at pubsub.xmpp.lobstermonster.org and do the
needed PubSub subscriptions

The first option is more user friendly since you just need to add the
contact to you roster, and when you want to unsubscribe, you just
remove the bbc-news -users from your contacts. And this feature should
be provided by almost all the XMPP clients rather than easy to use
PubSub -functionalism.

The other difference in this service is that when a new item is
published to the node, user bbc-news at xmpp.lobstermonster.org will send
you the item also as "clear message". This is done so that the service
is usable even with gMail's client.

I also wrote a small story about it on my web site:
http://www.lobstermonster.org/post/xmpp-pubsub-service-to-publish-bbc-world-news

If you have any ideas how the service could work better, don't
hesitate to yell out loud! And if you want me to add your favorite RSS
feed to be able to be subscribed like this, I can do that too.


Cheers,
--
tuomas

ps. sorry if someone get's this mail twice, I send it also to the
pubsub -mailing list.


From dave at cridland.net  Thu Apr 30 03:19:09 2009
From: dave at cridland.net (Dave Cridland)
Date: Thu, 30 Apr 2009 09:19:09 +0100
Subject: [jdev] (no subject)
In-Reply-To: <49F8CF03.10007@netmindz.net>
References: <49F8B45A.3030200@netmindz.net>
	<15169.1241036436.511912@puncture> <49F8CF03.10007@netmindz.net>
Message-ID: <20772.1241079549.140220@puncture>

On Wed Apr 29 23:04:51 2009, Will Tatam wrote:
> It has a whole stack of server dependencies, flash would just be  
> client side plus XMPP server of choice, not python, django,  
> postgresql ... etc

Ah, I thought Speeqe just needed BOSH.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade


From sdk at disktree.net  Thu Apr 30 04:57:45 2009
From: sdk at disktree.net (tong)
Date: Thu, 30 Apr 2009 11:57:45 +0200
Subject: [jdev] Flash conference
In-Reply-To: <49F8B45A.3030200@netmindz.net>
References: <49F8B45A.3030200@netmindz.net>
Message-ID: <1241085465.23015.17.camel@mini>

On Wed, 2009-04-29 at 21:11 +0100, Will Tatam wrote:
> Anyone recommend any pre-existing flash xmpp conference clients ? I'm 
> looking at add a flash chatroom to a site
> 
> I know I could build by own using XIFF but as i've not done and flash in 
> about 3 years a pre-existing one would be preferable
> 

our (haxe) hxmpp library supports flash9+ and muchat too.
since haxe 2.03 you can also output SWCs for reuse with AS3.

latest source is here:
http://disktree.spektral.at/git/?a=summary&p=hxmpp

i am not aware of a 'ready to go' muc flash-component.

best.tong


> _______________________________________________
> JDev mailing list
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________



From stpeter at stpeter.im  Thu Apr 30 11:23:27 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 30 Apr 2009 10:23:27 -0600
Subject: [jdev] [Fwd: [Standards] Call for Experience: XEP-0138 (Stream
	Compression)]
Message-ID: <49F9D07F.1070604@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

FYI.

- -------- Original Message --------
Subject: [Standards] Call for Experience: XEP-0138 (Stream Compression)
Date: Thu, 30 Apr 2009 10:13:27 -0600
From: Peter Saint-Andre <stpeter at stpeter.im>
Reply-To: XMPP Standards <standards at xmpp.org>
To: XMPP Extension Discussion List <standards at xmpp.org>

In its meeting yesterday, the XMPP Council agreed to issue a "Call for
Experience" regarding XEP-0138 (Stream Compression), in preparation for
perhaps advancing this specification from Draft to Final in the XSF's
standards process. To help the Council decide whether this XEP is ready
to advance to a status of Final, the Council would like to gather the
following information:

1. Who has implemented XEP-0138? Please note that the protocol must be
implemented in at least two separate codebases (and preferably more).

2. Have developers experienced any problems with the protocol as defined
in XEP-0138? If so, please describe the problems and, if possible,
suggested solutions.

3. Is the text of XEP-0138 clear and unambiguous? Are more examples
necessary? Is the conformance language (MAY/SHOULD/MUST) appropriate?
Have developers found the text confusing at all? Please describe any
suggestions you have for improving the text.

If you have any comments about advancing XEP-0138 from Draft to Final in
the XSF's standards process, please provide them by the close of
business on Friday, May 22, 2009. After the Call for Experience, this
XEP might undergo revisions to address feedback received, after which it
will be presented to the XMPP Council for voting to a status of Final.

You can review the XEP here:

http://www.xmpp.org/extensions/xep-0138.html

Please send all feedback to the standards at xmpp.org list.

Thanks!

Peter

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn50H8ACgkQNL8k5A2w/vyMaACg5XwXGo1FslHvqO26oRqigDAG
81sAoOFI4uuIkfZtWoB4FZ90tk/LnAey
=9ga6
-----END PGP SIGNATURE-----


From stpeter at stpeter.im  Thu Apr 30 11:23:43 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 30 Apr 2009 10:23:43 -0600
Subject: [jdev] [Fwd: [Standards] Call for Experience: XEP-0199 (XMPP Ping)]
Message-ID: <49F9D08F.20502@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

FYI.

- -------- Original Message --------
Subject: [Standards] Call for Experience: XEP-0199 (XMPP Ping)
Date: Thu, 30 Apr 2009 10:16:40 -0600
From: Peter Saint-Andre <stpeter at stpeter.im>
Reply-To: XMPP Standards <standards at xmpp.org>
To: XMPP Extension Discussion List <standards at xmpp.org>

In its meeting yesterday, the XMPP Council agreed to issue a "Call for
Experience" regarding XEP-0199 (XMPP Ping), in preparation for perhaps
advancing this specification from Draft to Final in the XSF's standards
process. To help the Council decide whether this XEP is ready to advance
to a status of Final, the Council would like to gather the following
information:

1. Who has implemented XEP-0199? Please note that the protocol must be
implemented in at least two separate codebases (and preferably more).

2. Have developers experienced any problems with the protocol as defined
in XEP-0199? If so, please describe the problems and, if possible,
suggested solutions.

3. Is the text of XEP-0199 clear and unambiguous? Are more examples
needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? Have
developers found the text confusing at all? Please describe any
suggestions you have for improving the text.

If you have any comments about advancing XEP-0199 from Draft to Final,
please provide them by the close of business on Friday, May 22, 2009.
After the Call for Experience, this XEP might undergo revisions to
address feedback received, after which it will be presented to the XMPP
Council for voting to a status of Final.

You can review the XEP here:

http://www.xmpp.org/extensions/xep-0199.html

Please send all feedback to the standards at xmpp.org list.

Thanks!

Peter


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn50I8ACgkQNL8k5A2w/vx9fwCg54KWg3I1LQn+I5N+MCrJn9C1
b3QAn3YSYO5mA0xFnuiUiOqElnoRF42x
=jRup
-----END PGP SIGNATURE-----


From stpeter at stpeter.im  Thu Apr 30 12:13:21 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 30 Apr 2009 11:13:21 -0600
Subject: [jdev] server RFP for jabber.org IM service
Message-ID: <49F9DC31.30604@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The jabber.org admin team has decided to issue an RFP for the XMPP
server software that runs the jabber.org IM service. Full information is
available here:

http://www.jabber.org/index.php/2009/04/server-rfp/

Please let me know if you have any questions.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn53DEACgkQNL8k5A2w/vybYwCg95KrzeBp39c8zkDWLjnfqoBl
nT8Anis9q4SOCFdP20C01UFOk4ygbp6h
=XU1+
-----END PGP SIGNATURE-----


From jonathan.dickinson at k2.com  Wed Apr  1 06:52:14 2009
From: jonathan.dickinson at k2.com (Jonathan Dickinson)
Date: Wed, 1 Apr 2009 13:52:14 +0200
Subject: [jdev] APML and PubSub
Message-ID: <A790BE8D83ECC3469047C2E344EABE61027C5A3F725B@zamail01.k2workflow.com>

Hi All,

I thought someone might want to do something interesting with this technology.

""APML allows users to share their own personal Attention Profile in much the same way that OPML allows the exchange of reading lists between News Readers. The idea is to compress all forms of Attention Data into a portable file format containing a description of ranked user interests.""

Given an APML binding for each PubSub node (e.g. "user interface") a PubSub service could provide a user with a list of suggested nodes based on an APML document that they provide (via IQ or something): or automatically send them publications in any node based on each publications' tags.

Furthermore, if the PubSub spec got a little 'smarter' the author could set the 'affinity' for each post's tag: allowing them to indicate how well the post relates to the particular tag. This could be used to filter publications based on the "value" attribute in the APML. Thus:

Known APMLs:
Fred:
 Food 0.6
 User Interface 0.9
Jane
 Food 0.8
 User Interface 0.3

Subscriber Creates Publication:
 Food (3/5 = 0.6 - Invert = 0.4)
 Sends to  Fred and Jane
Another one:
 User Interface (2/5 = 0.4 - Invert = 0.6)
 Sends to  Fred

Just some hashing out of some ideas; I don't have the time to really go at it. Just wanted to throw it out there and see what you all think: maybe someone will hop on it and write a XEP.

<http://www.apml.org/>

-- Jonathan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090401/b6ae5a4e/attachment-0003.htm>

From mwild1 at gmail.com  Wed Apr  1 11:58:55 2009
From: mwild1 at gmail.com (Matthew Wild)
Date: Wed, 1 Apr 2009 17:58:55 +0100
Subject: [jdev] [ANN] Prosody 0.4.0 Released
Message-ID: <4db9cacb0904010958je6769fbm9b7bfdd2e6090e9@mail.gmail.com>

We are pleased to announce the release of Prosody 0.4.0.

It's no joke. We have spent most effort this release improving
Prosody internals, ensuring we have a solid base on which to build
future features. Numerous bugs have been fixed and we recommend
that all users of 0.3.0 upgrade.

That said, we do have a few new things in this release, namely
roster versioning (allowing clients to cache the roster, instead
of downloading it each time they connect) and support for external
components, allowing the use of gateways/transports and other services.

Prosody is a lightweight Jabber/XMPP server written in Lua. It aims
to be flexible, easy to extend, and simple to use for both users
and developers alike.

The following is a summary of changes since the previous version:

   * Numerous stability fixes (highly recommended 0.3 users upgrade)
   * XEP-0114 support for external components (experimental)
   * mod_xmlrpc: Allow RPC calls over HTTP/XMPP to command a server
   * Roster versioning, to allow faster logins (experimental)
   * Fix BOSH race condition with multiple idle sessions
   * Handle missing <priority> in initial client presence
   * Fix for correct pass-through of stanzas with prefixed attributes
   * Fix routing of some stanzas directed to bare JIDs
   * Config improvements, better error reporting, Include command
   * SASL ANONYMOUS support for anonymous login when enabled
   * mod_version now reports OS type (configurable)
   * MUC: Support PMs, vCards, and misc. reliability fixes
   * Module API: Add stanza.clone, timers, and more
   * Various logging improvements

We would appreciate feedback from those testing roster versioning -
we are aware of no clients that support it currently, but hopefully
that can soon change.

Testing external component support would greatly help too, there
are many different components, and we have only tried a couple.

All of the known issues listed in the previous release have been fixed.

Download: http://prosody.im/download/

Happy Jabbering,
  The Prosody Team


From simon at buddycloud.com  Wed Apr  1 14:10:21 2009
From: simon at buddycloud.com (Simon Tennant)
Date: Wed, 01 Apr 2009 21:10:21 +0200
Subject: [jdev] update on XMPP location (wherein beer is offered)
In-Reply-To: <28B8BE8DCC88448192FEF978639142CC@movsoftware.com>
References: <28B8BE8DCC88448192FEF978639142CC@movsoftware.com>
Message-ID: <49D3BC1D.90504@buddycloud.com>

Stephen Pendleton wrote:
> I like this a lot. How does the "nearby" query work? Does it returned
> bookmarked places that are owned by the submitting jid, or any bookmarked
> place nearby? What is "cellpatternquality" mean?
A place can have one of two modes.

    * Public places are those that can be shared with other people. Eg
      my placemark for Starbucks would be useful to others.
    * Private places are those that will not be shared with others. For
      example my placemark called "Home sweet home" is probably not
      useful to others on the network (and/or I want it to be private to
      just me and only shared with my friends).

butler.buddycloud.com will only show public in a nearby query. These
will be public places from all users. Additionally you can subscribe to
a place which then places it on your own list of places that you are
placed at in the future.

CellPatternQuality reflects the certainty of the place.  How "distinct"
it is. For example when you are driving the location butler will be
seeing lots of new wifi and cell towers. Saving a placemark at that
point will save it but it will be a "blurry" pattern in the database. 
Better would be to wait a moment, submit a couple more location queries,
watch for the cellpatternquality to increase to 100% and then send a
placemark save stanza.  Then the butler will be far more likely to
accurately place you back at that point in the future.

> Also, how does the component push my location to my PEP node if I am on
> another server? Would this be allowed by XMPP servers? I would be
> interested
> in seeing these stanzas though to test it out.
Indeed for non-buddycloud.com domains PEP would not work. There are two
solutions for this that we are looking at. Either:

    * having the remote non buddycloud node publish their own pep node
      after getting a reply to their location query stanza or
    * granting publisher rights to butler.buddycloud.com on your own
      pubsub geoloc node and passing the address to this node as part of
      the location query. The query results would then be published on
      your behalf in XEP-0080 (user location) format as well as being
      returned to the client.

> There is another application we are working on that involves XEP-0255. It
> currently supports what you are calling "beacon logs" stanzas to
> return back
> postal addresses. The system uses a combination of wifi access
> points/mobile
> towers to pinpoint your position and return back a lat/lon. It is very
> accurate in a populated area.
The butler does a best effort on the lookup of lat/long too and
publishes it as part of the XEP-0080 stack. I don't think we fill out
the post code for general locations (we do for known places) but this
could presumably be added with access to the right lat/long -> postcode
mapping tables.  It's not something that we have spent too much time on.
Our main efforts in butler development have focused on making location
something social by describing it as known places like home or work or
"on the road in munich" (travelling) or  "near  Jo's house" for example.

S.

-- 
Simon Tennant
Buddycloud
uk: +44 20 7043 6756               de: +49 89 420 955 854  
uk: +44 78 5335 6047               de: +49 17 8545 0880
email and xmpp: simon at buddycloud.com
http://buddycloud.com



From stpeter at stpeter.im  Thu Apr  2 20:23:31 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 02 Apr 2009 19:23:31 -0600
Subject: [jdev] jabber.org account registration policy
Message-ID: <49D56513.5080201@stpeter.im>

http://www.jabber.org/index.php/2009/04/account-registration-policy/ says:

The Jabber.org IM service has instituted a new account registration
policy. Until further notice, IM accounts can be registered only via the
web at register.jabber.org, which means that our longtime practice of
allowing in-band registration using an IM client has been disabled.

You will notice that register.jabber.org requires you to complete a
?CAPTCHA? test in order to create an account. This is a security measure
to help prevent bulk account creation by automated processes. We might
deploy further account security measures in the future, and will
announce any such changes at the jabber.org website.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090402/4f15d829/attachment-0003.bin>

From stpeter at stpeter.im  Thu Apr  2 23:17:08 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 02 Apr 2009 22:17:08 -0600
Subject: [jdev] client developers take note: list of IM services
Message-ID: <49D58DC4.3080601@stpeter.im>

Because of yet another jabber.org website change, we've moved the XML
file that provides an automated listing of the public XMPP servers.

Originally it was here: http://jabber.org/servers.xml

Then it was here: http://jabber.org/basicservers.xml

Now it is here: http://xmpp.org/services/services.xml

HTTP redirects are supposed to be in place, but there is no guarantee
that they are working. Please verify and let me know.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090402/e248cb6a/attachment-0003.bin>

From elmex at x-paste.de  Fri Apr  3 03:44:01 2009
From: elmex at x-paste.de (Robin Redeker)
Date: Fri, 3 Apr 2009 10:44:01 +0200
Subject: [jdev] client developers take note: list of IM services
In-Reply-To: <49D58DC4.3080601@stpeter.im>
References: <49D58DC4.3080601@stpeter.im>
Message-ID: <20090403084400.GB10294@kiste.laendle>

On Thu, Apr 02, 2009 at 10:17:08PM -0600, Peter Saint-Andre wrote:
> Because of yet another jabber.org website change, we've moved the XML
> file that provides an automated listing of the public XMPP servers.
> 
> Originally it was here: http://jabber.org/servers.xml
> 
> Then it was here: http://jabber.org/basicservers.xml
> 
> Now it is here: http://xmpp.org/services/services.xml
> 
> HTTP redirects are supposed to be in place, but there is no guarantee
> that they are working. Please verify and let me know.

http://www.jabber.org/servers.xml redirects to http://xmpp.org/software/servers.shtml

which is a list of server software...

And http://jabber.org/basicservers.xml is a redirect to http://www.jabber.org/basicservers.xml
which is a redirect to http://www.xmpp.org/services/services.xml

And http://xmpp.org/services/services.xml is 404 Not Found.

Greetings,
   Robin

-- 
Robin Redeker                         | Deliantra, the free code+content MORPG
elmex at ta-sa.org / r.redeker at gmail.com | http://www.deliantra.net
http://www.ta-sa.org/                 |


From stpeter at stpeter.im  Fri Apr  3 08:11:25 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 03 Apr 2009 07:11:25 -0600
Subject: [jdev] client developers take note: list of IM services
In-Reply-To: <20090403084400.GB10294@kiste.laendle>
References: <49D58DC4.3080601@stpeter.im>
	<20090403084400.GB10294@kiste.laendle>
Message-ID: <49D60AFD.2050707@stpeter.im>

On 4/3/09 2:44 AM, Robin Redeker wrote:
> On Thu, Apr 02, 2009 at 10:17:08PM -0600, Peter Saint-Andre wrote:
>> Because of yet another jabber.org website change, we've moved the XML
>> file that provides an automated listing of the public XMPP servers.
>>
>> Originally it was here: http://jabber.org/servers.xml
>>
>> Then it was here: http://jabber.org/basicservers.xml
>>
>> Now it is here: http://xmpp.org/services/services.xml
>>
>> HTTP redirects are supposed to be in place, but there is no guarantee
>> that they are working. Please verify and let me know.
> 
> http://www.jabber.org/servers.xml redirects to http://xmpp.org/software/servers.shtml

Fixed.

> which is a list of server software...
> 
> And http://jabber.org/basicservers.xml is a redirect to http://www.jabber.org/basicservers.xml
> which is a redirect to http://www.xmpp.org/services/services.xml

Fixed.

> And http://xmpp.org/services/services.xml is 404 Not Found.

Fixed.

Thanks for testing!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090403/c2a97e83/attachment-0003.bin>

From sander at sanderdevrieze.net  Fri Apr  3 11:34:35 2009
From: sander at sanderdevrieze.net (Sander Devrieze)
Date: Fri, 3 Apr 2009 18:34:35 +0200
Subject: [jdev] jabber.org account registration policy
In-Reply-To: <49D56513.5080201@stpeter.im>
References: <49D56513.5080201@stpeter.im>
Message-ID: <7b06a4100904030934i68b16cc2h8bedf5e9127c0ebb@mail.gmail.com>

2009/4/3 Peter Saint-Andre <stpeter at stpeter.im>:
> http://www.jabber.org/index.php/2009/04/account-registration-policy/ says:
>
> The Jabber.org IM service has instituted a new account registration
> policy. Until further notice, IM accounts can be registered only via the
> web at register.jabber.org, which means that our longtime practice of
> allowing in-band registration using an IM client has been disabled.

Would it be possible to remove jabber.org from
http://xmpp.org/services/services.xml ? I think that list makes no
sense when it contains services which are not in-band registration
capable...


-- 
Mvg, Sander Devrieze.


From lambda512 at gmail.com  Sat Apr  4 07:30:57 2009
From: lambda512 at gmail.com (naw)
Date: Sat, 4 Apr 2009 14:30:57 +0200
Subject: [jdev] jabber.org account registration policy
In-Reply-To: <7b06a4100904030934i68b16cc2h8bedf5e9127c0ebb@mail.gmail.com>
References: <49D56513.5080201@stpeter.im>
	<7b06a4100904030934i68b16cc2h8bedf5e9127c0ebb@mail.gmail.com>
Message-ID: <200904041430.58372.lambda512@gmail.com>

El Viernes 03 Abril 2009, Sander Devrieze escribi?:
> 2009/4/3 Peter Saint-Andre <stpeter at stpeter.im>:
> > http://www.jabber.org/index.php/2009/04/account-registration-policy/
> > says:
> >
> > The Jabber.org IM service has instituted a new account registration
> > policy. Until further notice, IM accounts can be registered only via the
> > web at register.jabber.org, which means that our longtime practice of
> > allowing in-band registration using an IM client has been disabled.
>
> Would it be possible to remove jabber.org from
> http://xmpp.org/services/services.xml ? I think that list makes no
> sense when it contains services which are not in-band registration
> capable...

I think that it mades sense to have a list of federated servers. It can be 
useful for other things. But maybe there should be some aditional information 
about the servers (if they support in-band registration), or maybe several 
lists (e.g. one for all servers, another one for servers wich support 
in-band...)

Also, if in-band registration is going to be less used by servers until the 
implementation of XEP-0158 (captchas) in servers and clients, it could be 
also useful to provide the registration address as a child element in the 
list.

-- 

Jabber-ID: lambda512 at jabberes.org lambda512 at gmail.com


From stpeter at stpeter.im  Sat Apr  4 14:13:31 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Sat, 04 Apr 2009 13:13:31 -0600
Subject: [jdev] jabber.org account registration policy
In-Reply-To: <200904041430.58372.lambda512@gmail.com>
References: <49D56513.5080201@stpeter.im>	<7b06a4100904030934i68b16cc2h8bedf5e9127c0ebb@mail.gmail.com>
	<200904041430.58372.lambda512@gmail.com>
Message-ID: <49D7B15B.8070902@stpeter.im>

On 4/4/09 6:30 AM, naw wrote:
> El Viernes 03 Abril 2009, Sander Devrieze escribi?:
>> 2009/4/3 Peter Saint-Andre <stpeter at stpeter.im>:
>>> http://www.jabber.org/index.php/2009/04/account-registration-policy/
>>> says:
>>>
>>> The Jabber.org IM service has instituted a new account registration
>>> policy. Until further notice, IM accounts can be registered only via the
>>> web at register.jabber.org, which means that our longtime practice of
>>> allowing in-band registration using an IM client has been disabled.
>> Would it be possible to remove jabber.org from
>> http://xmpp.org/services/services.xml ? I think that list makes no
>> sense when it contains services which are not in-band registration
>> capable...

Done.

> I think that it mades sense to have a list of federated servers. It can be 
> useful for other things. But maybe there should be some aditional information 
> about the servers (if they support in-band registration), or maybe several 
> lists (e.g. one for all servers, another one for servers wich support 
> in-band...)

I think it's best if services.xml includes only services that support
in-band registration (IBR), because this file is used by clients to
present a list of services for account registration.

> Also, if in-band registration is going to be less used by servers until the 
> implementation of XEP-0158 (captchas) in servers and clients, it could be 
> also useful to provide the registration address as a child element in the 
> list.

Given the recent (and growing) problems with automated processes
registering large numbers of accounts on public XMPP services, I think
that IBR will soon become unworkable without XEP-0158 support in clients
and servers. Until that happens, we will diable IBR at jabber.org (and I
expect many other public XMPP services to do the same). IBR was a great
idea back in 1999 when no one had ever heard of Jabber, but these days
it is very close to hazardous for the health of the network.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090404/cac8fa3e/attachment-0003.bin>

From mikemendel at gmail.com  Sat Apr  4 16:00:06 2009
From: mikemendel at gmail.com (mikemendel)
Date: Sat,  4 Apr 2009 16:00:06 -0500 (CDT)
Subject: [jdev] mikemendel has invited you to join SlideShare
Message-ID: <20090404210006.ACF9E21AD64@atlas.jabber.org>

An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090404/aa6fde85/attachment-0003.htm>

From pendleto at movsoftware.com  Mon Apr  6 09:57:23 2009
From: pendleto at movsoftware.com (Stephen Pendleton)
Date: Mon, 6 Apr 2009 10:57:23 -0400
Subject: [jdev] update on XMPP location (wherein beer is offered)
In-Reply-To: <49D3BC1D.90504@buddycloud.com>
Message-ID: <9090DBE6366A4B5C8CEEC37CC2799F1C@movsoftware.com>

I can't seem to get this to work. For example I send:

<iq to="butler.buddycloud.com" type="get" xml:lang="en" id="location1">
	<locationquery xmlns="urn:xmpp:locationquery:0">
		<timestamp>2009-04-05T08:09:56Z</timestamp>
		<publish>true</publish>
		<reference>
			<id>262:07:51520:34124757</id>
			<type>cell</type>
			<signalstrength>88</signalstrength>
		</reference>		
	</locationquery>
	<locationquery xmlns="urn:xmpp:locationquery:0">
		<timestamp>2009-04-05T08:09:56Z</timestamp>
		<reference>
			<id>262:07:51520:34104756</id>
			<type>cell</type>
			<signalstrength>88</signalstrength>
		</reference>		
	</locationquery>
	<locationquery xmlns="urn:xmpp:locationquery:0">
		<timestamp>2009-04-05T08:09:56Z</timestamp>
		<reference>
			<id>262:07:51520:34084753</id>
			<type>cell</type>
			<signalstrength>88</signalstrength>
		</reference>		
	</locationquery>
</iq>
and I get back the placename OK. I then send the nearby places query and get
an error back:

<iq to="butler.buddycloud.com" type="get" id="nearbyplaces1">
	<command xmlns="http://jabber.org/protocol/commands"
node="location">
		<x xmlns="jabber:x:data" type="form">
			<field type="hidden" var="FORM_TYPE">
	
<value>buddycloud:location:places_near</value>
			</field>
		</x>
	</command>
</iq>

and get back:
<iq from="butler.buddycloud.com" to="spendleton at movsoftware.com/spark"
id="nearbyplaces1" type="error" xml:lang="en-GB">
	<command xmlns="http://jabber.org/protocol/commands"
node="location">
		<x xmlns="jabber:x:data" type="form">
			<field type="hidden" var="FORM_TYPE">
	
<value>buddycloud:location:places_near</value>
			</field>
		</x>
	</command>
<error code="500" type="wait"><internal-server-error
xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/><text
xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/></error></iq>


Also, I dont understand the <publish>true</publish> stanza. In the case
where I am sending cellids what is it publishing to my PEP node? Not my
lat/lon right, because you do not have lat/lon mappings from cellids to
lat/long coordinates and I dont have a placename published with that
lat/lon.

Also, if I remove or set the <publish> to <publish>false</publish> I get
back:

iq from="butler.buddycloud.com" to="spendleton at movsoftware.com/spark"
id="location31" type="result"><geoloc
xmlns="http://jabber.org/protocol/geoloc"
xml:lang="en"><accuracy>1000000</accuracy></geoloc></iq>

Not sure what this means.

Thanks
-----Original Message-----
From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] On Behalf Of
Simon Tennant
Sent: 04/01/2009 3:10 PM
To: Jabber/XMPP software development list
Subject: Re: [jdev] update on XMPP location (wherein beer is offered)


Stephen Pendleton wrote:
> I like this a lot. How does the "nearby" query work? Does it returned 
> bookmarked places that are owned by the submitting jid, or any 
> bookmarked place nearby? What is "cellpatternquality" mean?
A place can have one of two modes.

    * Public places are those that can be shared with other people. Eg
      my placemark for Starbucks would be useful to others.
    * Private places are those that will not be shared with others. For
      example my placemark called "Home sweet home" is probably not
      useful to others on the network (and/or I want it to be private to
      just me and only shared with my friends).

butler.buddycloud.com will only show public in a nearby query. These will be
public places from all users. Additionally you can subscribe to a place
which then places it on your own list of places that you are placed at in
the future.

CellPatternQuality reflects the certainty of the place.  How "distinct" it
is. For example when you are driving the location butler will be seeing lots
of new wifi and cell towers. Saving a placemark at that point will save it
but it will be a "blurry" pattern in the database. 
Better would be to wait a moment, submit a couple more location queries,
watch for the cellpatternquality to increase to 100% and then send a
placemark save stanza.  Then the butler will be far more likely to
accurately place you back at that point in the future.

> Also, how does the component push my location to my PEP node if I am 
> on another server? Would this be allowed by XMPP servers? I would be 
> interested in seeing these stanzas though to test it out.
Indeed for non-buddycloud.com domains PEP would not work. There are two
solutions for this that we are looking at. Either:

    * having the remote non buddycloud node publish their own pep node
      after getting a reply to their location query stanza or
    * granting publisher rights to butler.buddycloud.com on your own
      pubsub geoloc node and passing the address to this node as part of
      the location query. The query results would then be published on
      your behalf in XEP-0080 (user location) format as well as being
      returned to the client.

> There is another application we are working on that involves XEP-0255. 
> It currently supports what you are calling "beacon logs" stanzas to 
> return back postal addresses. The system uses a combination of wifi 
> access points/mobile
> towers to pinpoint your position and return back a lat/lon. It is very
> accurate in a populated area.
The butler does a best effort on the lookup of lat/long too and publishes it
as part of the XEP-0080 stack. I don't think we fill out the post code for
general locations (we do for known places) but this could presumably be
added with access to the right lat/long -> postcode mapping tables.  It's
not something that we have spent too much time on. Our main efforts in
butler development have focused on making location something social by
describing it as known places like home or work or "on the road in munich"
(travelling) or  "near  Jo's house" for example.

S.

-- 
Simon Tennant
Buddycloud
uk: +44 20 7043 6756               de: +49 89 420 955 854  
uk: +44 78 5335 6047               de: +49 17 8545 0880
email and xmpp: simon at buddycloud.com
http://buddycloud.com

_______________________________________________
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: JDev-unsubscribe at jabber.org
_______________________________________________




From helge at buddycloud.com  Mon Apr  6 13:33:27 2009
From: helge at buddycloud.com (Helge Timenes)
Date: Mon, 06 Apr 2009 20:33:27 +0200
Subject: [jdev] update on XMPP location (wherein beer is offered)
In-Reply-To: <9090DBE6366A4B5C8CEEC37CC2799F1C@movsoftware.com>
References: <9090DBE6366A4B5C8CEEC37CC2799F1C@movsoftware.com>
Message-ID: <49DA4AF7.1080806@buddycloud.com>

Stephen Pendleton wrote:
> I can't seem to get this to work. For example I send:
>
> <iq to="butler.buddycloud.com" type="get" xml:lang="en" id="location1">
> 	<locationquery xmlns="urn:xmpp:locationquery:0">
> 		<timestamp>2009-04-05T08:09:56Z</timestamp>
> 		<publish>true</publish>
> 		<reference>
> 			<id>262:07:51520:34124757</id>
> 			<type>cell</type>
> 			<signalstrength>88</signalstrength>
> 		</reference>		
> 	</locationquery>
> 	<locationquery xmlns="urn:xmpp:locationquery:0">
> 		<timestamp>2009-04-05T08:09:56Z</timestamp>
> 		<reference>
> 			<id>262:07:51520:34104756</id>
> 			<type>cell</type>
> 			<signalstrength>88</signalstrength>
> 		</reference>		
> 	</locationquery>
> 	<locationquery xmlns="urn:xmpp:locationquery:0">
> 		<timestamp>2009-04-05T08:09:56Z</timestamp>
> 		<reference>
> 			<id>262:07:51520:34084753</id>
> 			<type>cell</type>
> 			<signalstrength>88</signalstrength>
> 		</reference>		
> 	</locationquery>
> </iq>
>   
At the moment our server don't like multiple <locationquery> elements in 
an <iq>. There is no particularly good reason for this and I will fix it.

> and I get back the placename OK. I then send the nearby places query and get
> an error back:
>
> <iq to="butler.buddycloud.com" type="get" id="nearbyplaces1">
> 	<command xmlns="http://jabber.org/protocol/commands"
> node="location">
> 		<x xmlns="jabber:x:data" type="form">
> 			<field type="hidden" var="FORM_TYPE">
> 	
> <value>buddycloud:location:places_near</value>
> 			</field>
> 		</x>
> 	</command>
> </iq>
>
> and get back:
> <iq from="butler.buddycloud.com" to="spendleton at movsoftware.com/spark"
> id="nearbyplaces1" type="error" xml:lang="en-GB">
> 	<command xmlns="http://jabber.org/protocol/commands"
> node="location">
> 		<x xmlns="jabber:x:data" type="form">
> 			<field type="hidden" var="FORM_TYPE">
> 	
> <value>buddycloud:location:places_near</value>
> 			</field>
> 		</x>
> 	</command>
> <error code="500" type="wait"><internal-server-error
> xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/><text
> xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/></error></iq>
>
>
>   
Something wrong was probably not right there (!) Possibly to do with the 
above.
> Also, I dont understand the <publish>true</publish> stanza. In the case
> where I am sending cellids what is it publishing to my PEP node? Not my
> lat/lon right, because you do not have lat/lon mappings from cellids to
> lat/long coordinates and I dont have a placename published with that
> lat/lon.
>   
It will publish as much info as can be derived from your references. We 
do have a rudimentary cell to lat/lon database, and if a match is found 
it wil use this to derive your coordinates. If not it will default to 
the center of your country (derived from MCC) associated with a huuuuge 
error. From lat/lon it will try to obtain region, city and area names 
(with a little help from geonames.org).

Note that the publish will most likely fail, since your host server will 
propably let our server publish to your PEP node on your behalf. Some 
configuration might be needed for this to work I believe.
> Also, if I remove or set the <publish> to <publish>false</publish> I get
> back:
>
> iq from="butler.buddycloud.com" to="spendleton at movsoftware.com/spark"
> id="location31" type="result"><geoloc
> xmlns="http://jabber.org/protocol/geoloc"
> xml:lang="en"><accuracy>1000000</accuracy></geoloc></iq>
>
> Not sure what this means.
>   
This is probably related to your error above. Some how no results could 
be found (even so it suggest an error for your location had it been 
found. Er...  right)
> Thanks
>   
Your're welcome


From gnauck at ag-software.de  Mon Apr  6 14:10:58 2009
From: gnauck at ag-software.de (Alexander Gnauck)
Date: Mon, 06 Apr 2009 21:10:58 +0200
Subject: [jdev] XSF membership application period Q2/2009
Message-ID: <49DA53C2.90006@ag-software.de>

The XMPP Standards Foundation (XSF) is currently holding its quarterly 
membership application period:
http://wiki.xmpp.org/web/Membership_Applications_April_2009

Applications are encouraged from developers and others who are actively 
involved in the Jabber/XMPP community. To apply, create a page about 
yourself on the wiki.

If you don't have a wiki account, send your name, preferred nickname and
email address to me or one of the other Sysops:
http://wiki.xmpp.org/index.php/Sysops

The application period ends on 22th April 2009 23:59h UTC, so apply today!

Regards,
Alex
--
Alexander Gnauck
xmpp:gnauck at jabber.org


From waqas20 at gmail.com  Mon Apr  6 14:27:08 2009
From: waqas20 at gmail.com (Waqas Hussain)
Date: Tue, 7 Apr 2009 00:27:08 +0500
Subject: [jdev] update on XMPP location (wherein beer is offered)
In-Reply-To: <49DA4AF7.1080806@buddycloud.com>
References: <9090DBE6366A4B5C8CEEC37CC2799F1C@movsoftware.com>
	<49DA4AF7.1080806@buddycloud.com>
Message-ID: <7fc4fa880904061227k7a31a66fxea5375a3d196af5b@mail.gmail.com>

On Mon, Apr 6, 2009 at 11:33 PM, Helge Timenes <helge at buddycloud.com> wrote:
> Stephen Pendleton wrote:
>> I can't seem to get this to work. For example I send:
>>
>> <iq to="butler.buddycloud.com" type="get" xml:lang="en" id="location1">
>> ? ? ? <locationquery xmlns="urn:xmpp:locationquery:0">
>> ? ? ? ? ? ? ? <timestamp>2009-04-05T08:09:56Z</timestamp>
>> ? ? ? ? ? ? ? <publish>true</publish>
>> ? ? ? ? ? ? ? <reference>
>> ? ? ? ? ? ? ? ? ? ? ? <id>262:07:51520:34124757</id>
>> ? ? ? ? ? ? ? ? ? ? ? <type>cell</type>
>> ? ? ? ? ? ? ? ? ? ? ? <signalstrength>88</signalstrength>
>> ? ? ? ? ? ? ? </reference>
>> ? ? ? </locationquery>
>> ? ? ? <locationquery xmlns="urn:xmpp:locationquery:0">
>> ? ? ? ? ? ? ? <timestamp>2009-04-05T08:09:56Z</timestamp>
>> ? ? ? ? ? ? ? <reference>
>> ? ? ? ? ? ? ? ? ? ? ? <id>262:07:51520:34104756</id>
>> ? ? ? ? ? ? ? ? ? ? ? <type>cell</type>
>> ? ? ? ? ? ? ? ? ? ? ? <signalstrength>88</signalstrength>
>> ? ? ? ? ? ? ? </reference>
>> ? ? ? </locationquery>
>> ? ? ? <locationquery xmlns="urn:xmpp:locationquery:0">
>> ? ? ? ? ? ? ? <timestamp>2009-04-05T08:09:56Z</timestamp>
>> ? ? ? ? ? ? ? <reference>
>> ? ? ? ? ? ? ? ? ? ? ? <id>262:07:51520:34084753</id>
>> ? ? ? ? ? ? ? ? ? ? ? <type>cell</type>
>> ? ? ? ? ? ? ? ? ? ? ? <signalstrength>88</signalstrength>
>> ? ? ? ? ? ? ? </reference>
>> ? ? ? </locationquery>
>> </iq>
>>
> At the moment our server don't like multiple <locationquery> elements in
> an <iq>. There is no particularly good reason for this and I will fix it.
>

There is a particularly good reason for this: IQ gets and sets are
only allowed to have a single child.

Don't 'fix' this, because accepting multiple IQ children would break
the XMPP spec.

--
Waqas Hussain


From helge at buddycloud.com  Mon Apr  6 14:40:49 2009
From: helge at buddycloud.com (Helge Timenes)
Date: Mon, 06 Apr 2009 21:40:49 +0200
Subject: [jdev] update on XMPP location (wherein beer is offered)
In-Reply-To: <7fc4fa880904061227k7a31a66fxea5375a3d196af5b@mail.gmail.com>
References: <9090DBE6366A4B5C8CEEC37CC2799F1C@movsoftware.com>	<49DA4AF7.1080806@buddycloud.com>
	<7fc4fa880904061227k7a31a66fxea5375a3d196af5b@mail.gmail.com>
Message-ID: <49DA5AC1.6050602@buddycloud.com>

Waqas Hussain wrote:
> On Mon, Apr 6, 2009 at 11:33 PM, Helge Timenes <helge at buddycloud.com> wrote:
>   
>> Stephen Pendleton wrote:
>>     
>>> I can't seem to get this to work. For example I send:
>>>
>>> <iq to="butler.buddycloud.com" type="get" xml:lang="en" id="location1">
>>>       <locationquery xmlns="urn:xmpp:locationquery:0">
>>>               <timestamp>2009-04-05T08:09:56Z</timestamp>
>>>               <publish>true</publish>
>>>               <reference>
>>>                       <id>262:07:51520:34124757</id>
>>>                       <type>cell</type>
>>>                       <signalstrength>88</signalstrength>
>>>               </reference>
>>>       </locationquery>
>>>       <locationquery xmlns="urn:xmpp:locationquery:0">
>>>               <timestamp>2009-04-05T08:09:56Z</timestamp>
>>>               <reference>
>>>                       <id>262:07:51520:34104756</id>
>>>                       <type>cell</type>
>>>                       <signalstrength>88</signalstrength>
>>>               </reference>
>>>       </locationquery>
>>>       <locationquery xmlns="urn:xmpp:locationquery:0">
>>>               <timestamp>2009-04-05T08:09:56Z</timestamp>
>>>               <reference>
>>>                       <id>262:07:51520:34084753</id>
>>>                       <type>cell</type>
>>>                       <signalstrength>88</signalstrength>
>>>               </reference>
>>>       </locationquery>
>>> </iq>
>>>
>>>       
>> At the moment our server don't like multiple <locationquery> elements in
>> an <iq>. There is no particularly good reason for this and I will fix it.
>>
>>     
>
> There is a particularly good reason for this: IQ gets and sets are
> only allowed to have a single child.
>
> Don't 'fix' this, because accepting multiple IQ children would break
> the XMPP spec.
>
>   
Right, silly of me. Fix cancelled.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090406/dd6fc296/attachment-0003.htm>

From fippo at goodadvice.pages.de  Mon Apr  6 14:42:49 2009
From: fippo at goodadvice.pages.de (Philipp Hancke)
Date: Mon, 06 Apr 2009 21:42:49 +0200
Subject: [jdev] update on XMPP location (wherein beer is offered)
In-Reply-To: <7fc4fa880904061227k7a31a66fxea5375a3d196af5b@mail.gmail.com>
References: <9090DBE6366A4B5C8CEEC37CC2799F1C@movsoftware.com>	<49DA4AF7.1080806@buddycloud.com>
	<7fc4fa880904061227k7a31a66fxea5375a3d196af5b@mail.gmail.com>
Message-ID: <49DA5B39.8050905@goodadvice.pages.de>

Waqas Hussain wrote:
> There is a particularly good reason for this: IQ gets and sets are
> only allowed to have a single child.
> 
> Don't 'fix' this, because accepting multiple IQ children would break
> the XMPP spec.

and because XEP 0255 - example 7 shows the right way to do it.


From pendleto at movsoftware.com  Mon Apr  6 15:12:09 2009
From: pendleto at movsoftware.com (Stephen Pendleton)
Date: Mon, 6 Apr 2009 16:12:09 -0400
Subject: [jdev] update on XMPP location (wherein beer is offered)
In-Reply-To: <7fc4fa880904061227k7a31a66fxea5375a3d196af5b@mail.gmail.com>
Message-ID: <693A5CF4B33B4EBBB0913659D3F8F147@movsoftware.com>

My mistake. I meant to say I sent:

<iq to="butler.buddycloud.com" type="get" xml:lang="en" id="location1">
	<locationquery xmlns="urn:xmpp:locationquery:0">
		<reference>
			<id>262:07:51520:34124757</id>
			<type>cell</type>
			<signalstrength>88</signalstrength>
		</reference>		
		<reference>
			<id>262:07:51520:34104756</id>
			<type>cell</type>
			<signalstrength>88</signalstrength>
		</reference>		
		<reference>
			<id>262:07:51520:34084753</id>
			<type>cell</type>
			<signalstrength>88</signalstrength>
		</reference>		
	</locationquery>
</iq>

-----Original Message-----
From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] On Behalf Of
Waqas Hussain
Sent: 04/06/2009 3:27 PM
To: Jabber/XMPP software development list
Subject: Re: [jdev] update on XMPP location (wherein beer is offered)


On Mon, Apr 6, 2009 at 11:33 PM, Helge Timenes <helge at buddycloud.com> wrote:
> Stephen Pendleton wrote:
>> I can't seem to get this to work. For example I send:
>>
>> <iq to="butler.buddycloud.com" type="get" xml:lang="en" 
>> id="location1">
>> ? ? ? <locationquery xmlns="urn:xmpp:locationquery:0">
>> ? ? ? ? ? ? ? <timestamp>2009-04-05T08:09:56Z</timestamp>
>> ? ? ? ? ? ? ? <publish>true</publish>
>> ? ? ? ? ? ? ? <reference>
>> ? ? ? ? ? ? ? ? ? ? ? <id>262:07:51520:34124757</id>
>> ? ? ? ? ? ? ? ? ? ? ? <type>cell</type>
>> ? ? ? ? ? ? ? ? ? ? ? <signalstrength>88</signalstrength>
>> ? ? ? ? ? ? ? </reference>
>> ? ? ? </locationquery>
>> ? ? ? <locationquery xmlns="urn:xmpp:locationquery:0">
>> ? ? ? ? ? ? ? <timestamp>2009-04-05T08:09:56Z</timestamp>
>> ? ? ? ? ? ? ? <reference>
>> ? ? ? ? ? ? ? ? ? ? ? <id>262:07:51520:34104756</id>
>> ? ? ? ? ? ? ? ? ? ? ? <type>cell</type>
>> ? ? ? ? ? ? ? ? ? ? ? <signalstrength>88</signalstrength>
>> ? ? ? ? ? ? ? </reference>
>> ? ? ? </locationquery>
>> ? ? ? <locationquery xmlns="urn:xmpp:locationquery:0">
>> ? ? ? ? ? ? ? <timestamp>2009-04-05T08:09:56Z</timestamp>
>> ? ? ? ? ? ? ? <reference>
>> ? ? ? ? ? ? ? ? ? ? ? <id>262:07:51520:34084753</id>
>> ? ? ? ? ? ? ? ? ? ? ? <type>cell</type>
>> ? ? ? ? ? ? ? ? ? ? ? <signalstrength>88</signalstrength>
>> ? ? ? ? ? ? ? </reference>
>> ? ? ? </locationquery>
>> </iq>
>>
> At the moment our server don't like multiple <locationquery> elements 
> in an <iq>. There is no particularly good reason for this and I will 
> fix it.
>

There is a particularly good reason for this: IQ gets and sets are only
allowed to have a single child.

Don't 'fix' this, because accepting multiple IQ children would break the
XMPP spec.

--
Waqas Hussain
_______________________________________________
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: JDev-unsubscribe at jabber.org
_______________________________________________




From stpeter at stpeter.im  Mon Apr  6 23:20:45 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 06 Apr 2009 22:20:45 -0600
Subject: [jdev] jabber disk ?
In-Reply-To: <200903222325.n2MNPGCE017257@zogzog.maillard.mobi>
References: <200903222325.n2MNPGCE017257@zogzog.maillard.mobi>
Message-ID: <49DAD49D.2000707@stpeter.im>

On 3/22/09 5:25 PM, Xavier Maillard wrote:
> Hi,
> 
> I am writting a text editor with the aim to publish
> notes/articles/whatever over XMPP. I have all the basic editor
> stuff working and now has come the time to choose how to
> effectively "publish" these texts.
> 
> My goal behind this, is to have access to my notes anywhere at
> anytime. I am not sure what the best method I should choose to
> store all this stuff. I know there were tries to have webdav over
> XMPP, I know there is pubsub (which has my preference)  and
> lately I felt upon something called "jabdisk". I am looking for
> information about the later.
> 
> OTOH, if you have any idea on a global storage strategy for my
> client, feel free to share them :)
> 
> My main interest in writing this software is to be able to run a
> "jabber site" (aka a website) totally via XMPP and particulary a
> "XMPP wiki".

Why? Isn't that what HTTP is for?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090406/5640f1a3/attachment-0003.bin>

From christopher.zorn at gmail.com  Wed Apr  8 10:29:08 2009
From: christopher.zorn at gmail.com (Christopher Zorn)
Date: Wed, 8 Apr 2009 11:29:08 -0400
Subject: [jdev] ANN. Couchdb Backend
Message-ID: <149014b90904080829g642de4e4l684b530a0a6e7cbd@mail.gmail.com>

Just wanted to announce that I started a couchdb backend for ejabberd.

I did not create a ticket because I did not know if it fit. Also, it would
be nice to see how many people are interested in it before it is formal.

It is located on github.

http://thetofu.com/archive/ejabberd_couchdb_20090407.html
http://github.com/twonds/ejabberd_couchdb/tree/master

Relax and enjoy. ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090408/61894de8/attachment-0003.htm>

From thiranjith at gmail.com  Wed Apr  8 14:26:12 2009
From: thiranjith at gmail.com (Thiranjith .)
Date: Thu, 9 Apr 2009 07:26:12 +1200
Subject: [jdev] Using XMPP to talk to a mobile client
Message-ID: <2ec5902e0904081226v734582e9ib30ebca6c2f7ce18@mail.gmail.com>

Hi,

Can we use XMPP to talk to a client on a mobile device (e.g. PDA/ mobile
phone) that is connected to the internet using 3G? From what I understand,
phones' end-point IP changes as they move around, and generally they are
behind the network operator's (At&T, Vodafone etc) firewall.

Say that user 'A' sends a message to our mobile client. From what I
understand, the message will go through the XMPP server (e.g. Jabber.org or
our own) to find where our client is, so it can route the message. How would
the XMPP server know where to find our client in the place? The IP our
client used when registering with the server could be different now because
it could have moved around.

Does the mobile client need to periodically notify the server about its IP?
>From what I understand, the BOSH technique described in
http://xmpp.org/extensions/xep-0124.html#intro is meant to address this, but
it seems to work only if the entity behind the firewall initiate the
connection first (in this case, the client running within the mobile phone).

Please correct me if I got all this wrong as I am new to XMPP, but I would
greately appreciate if anyone can explain how the xmpp server finds the
mobile client that is on the move. Does our sever needs to implement that
routing logic ourselves? Any articles explaining this would also be great!

Thank you!
Thira
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090409/3193c548/attachment-0002.htm>

From stpeter at stpeter.im  Wed Apr  8 14:44:11 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 08 Apr 2009 13:44:11 -0600
Subject: [jdev] Monthly XMPP Meeting #2
Message-ID: <49DCFE8B.3080201@stpeter.im>

Although I never sent out minutes from the first "Monthly XMPP Meeting",
I think it would be productive to hold another meeting again soon. I
propose next Tuesday, April 14, at 20:00 UTC (check your local times!)
in the jdev at conference.jabber.org room.

See you there!

Peter

P.S. Maybe I'll get a change to write up the minutes from MXM #1 before
then:

http://logs.jabber.org/jdev at conference.jabber.org/2009-03-12.html


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090408/e8235b02/attachment-0003.bin>

From fabio.forno at gmail.com  Wed Apr  8 16:37:47 2009
From: fabio.forno at gmail.com (Fabio Forno)
Date: Wed, 8 Apr 2009 23:37:47 +0200
Subject: [jdev] Using XMPP to talk to a mobile client
In-Reply-To: <2ec5902e0904081226v734582e9ib30ebca6c2f7ce18@mail.gmail.com>
References: <2ec5902e0904081226v734582e9ib30ebca6c2f7ce18@mail.gmail.com>
Message-ID: <2fd53c3a0904081437q2d364a2w8e0b69d5b404a00@mail.gmail.com>

On Wed, Apr 8, 2009 at 9:26 PM, Thiranjith . <thiranjith at gmail.com> wrote:
> Hi,
>
> Can we use XMPP to talk to a client on a mobile device (e.g. PDA/ mobile
> phone) that is connected to the internet using 3G? From what I understand,
> phones' end-point IP changes as they move around, and generally they are
> behind the network operator's (At&T, Vodafone etc) firewall.
>
> Say that user 'A' sends a message to our mobile client. From what I
> understand, the message will go through the XMPP server (e.g. Jabber.org or
> our own) to find where our client is, so it can route the message. How would
> the XMPP server know where to find our client in the place? The IP our
> client used when registering with the server could be different now because
> it could have moved around.

As far as you are online with your client a socket is being kept open
with the server, thus allowing to push stanzas to your device. No need
to communicate your IP, just listen for incoming messages. You may try
one of the several clients listed here
http://xmpp.org/software/clients.shtml#mobile

Most networks will maintain your IP while moving to different cells,
and if you get disconnected it's up to the client to reopen a session
with the server

The situation is different while you are disconnected. In that case
the server stores the messages in the offline storage until the client
goes online

If you have urgent messages you can use an SMS for automatically
waking up the client, however this is a service that has a cost


> Does the mobile client need to periodically notify the server about its IP?
> From what I understand, the BOSH technique described in
> http://xmpp.org/extensions/xep-0124.html#intro is meant to address this, but
> it seems to work only if the entity behind the firewall initiate the
> connection first (in this case, the client running within the mobile phone).

BOSH likes tecniques are just used to pass through proxies or run
clients in web browsers. They may be used in order to improve
connection reliability, but a new and better method (xep-0198) is
being defined for this purpose.

-- 
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: ff at jabber.bluendo.com


From jonathan.dickinson at k2.com  Thu Apr  9 02:28:24 2009
From: jonathan.dickinson at k2.com (Jonathan Dickinson)
Date: Thu, 9 Apr 2009 09:28:24 +0200
Subject: [jdev] Using XMPP to talk to a mobile client
In-Reply-To: <2fd53c3a0904081437q2d364a2w8e0b69d5b404a00@mail.gmail.com>
References: <2ec5902e0904081226v734582e9ib30ebca6c2f7ce18@mail.gmail.com>
	<2fd53c3a0904081437q2d364a2w8e0b69d5b404a00@mail.gmail.com>
Message-ID: <A790BE8D83ECC3469047C2E344EABE61027C6442096B@zamail01.k2workflow.com>

> -----Original Message-----
> From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] On
> Behalf Of Fabio Forno
> Sent: 08 April 2009 11:38 PM
> To: Jabber/XMPP software development list
> Subject: Re: [jdev] Using XMPP to talk to a mobile client
> 
> On Wed, Apr 8, 2009 at 9:26 PM, Thiranjith . <thiranjith at gmail.com>
> wrote:
> > Hi,
> >
> > Can we use XMPP to talk to a client on a mobile device (e.g. PDA/
> mobile
> > phone) that is connected to the internet using 3G? From what I
> understand,
> > phones' end-point IP changes as they move around, and generally they
> are
> > behind the network operator's (At&T, Vodafone etc) firewall.
> >

IPv6 is supposed to address situations in regard to mobile devices. Although I am not entirely sure how well the technologies have been deployed. IIRC most mobile operators use NAT to connect clients to the internet, this means that the NAT will do what it can to keep your socket connections alive - in other words, mobile devices are less reliable (because they can lose signal entirely), but still completely viable (because the operators generally have this kind of stuff in mind).

My Windows Mobile phone has IPv6 and I have been able to access the IPv6 test website - if it works in a backwards country like South Africa it's gotta work in America and the UK!!!
 
> > Does the mobile client need to periodically notify the server about
> its IP?

No and yes. As I said this should be handled by your operator's NAT: test the system and find out (connect to a XMPP server and go on a road trip). If it isn't you should definitely raise a stink.

Yes in terms that, primarily, if your public IP (i.e. one of your operator's IP addresses) changes chances are you are going to get clean disconnected. If this happens your client should reconnect automatically - and as a side effect of this the server gets your new IP.

> 
> --
> Fabio Forno, Ph.D.
> Bluendo srl http://www.bluendo.com
> jabber id: ff at jabber.bluendo.com
> _______________________________________________
> JDev mailing list
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________


From mridulm80 at yahoo.com  Thu Apr  9 06:20:26 2009
From: mridulm80 at yahoo.com (Mridul Muralidharan)
Date: Thu, 9 Apr 2009 16:50:26 +0530 (IST)
Subject: [jdev] Using XMPP to talk to a mobile client
Message-ID: <907698.28410.qm@web95414.mail.in2.yahoo.com>




Just to mention, BOSH does not have any same client IP requirement/restriction.

And unlike tcp binding of xmpp - where session is terminated if disconnected, BOSH does handle disconnects in its design.

The only requirements would be -

a) ability of the client to connect back before the session/idle timeout.
b) BOSH gateway not going down.
c) BOSH client not going down.

b and c are mentioned - so that the session state (rid, etc) is not lost.

Regards,
Mridul



--- On Thu, 9/4/09, Jonathan Dickinson <jonathan.dickinson at k2.com> wrote:

> From: Jonathan Dickinson <jonathan.dickinson at k2.com>
> Subject: Re: [jdev] Using XMPP to talk to a mobile client
> To: "Jabber/XMPP software development list" <jdev at jabber.org>
> Date: Thursday, 9 April, 2009, 12:58 PM
> > -----Original Message-----
> > From: jdev-bounces at jabber.org
> [mailto:jdev-bounces at jabber.org]
> On
> > Behalf Of Fabio Forno
> > Sent: 08 April 2009 11:38 PM
> > To: Jabber/XMPP software development list
> > Subject: Re: [jdev] Using XMPP to talk to a mobile
> client
> > 
> > On Wed, Apr 8, 2009 at 9:26 PM, Thiranjith . <thiranjith at gmail.com>
> > wrote:
> > > Hi,
> > >
> > > Can we use XMPP to talk to a client on a mobile
> device (e.g. PDA/
> > mobile
> > > phone) that is connected to the internet using
> 3G? From what I
> > understand,
> > > phones' end-point IP changes as they move around,
> and generally they
> > are
> > > behind the network operator's (At&T, Vodafone
> etc) firewall.
> > >
> 
> IPv6 is supposed to address situations in regard to mobile
> devices. Although I am not entirely sure how well the
> technologies have been deployed. IIRC most mobile operators
> use NAT to connect clients to the internet, this means that
> the NAT will do what it can to keep your socket connections
> alive - in other words, mobile devices are less reliable
> (because they can lose signal entirely), but still
> completely viable (because the operators generally have this
> kind of stuff in mind).
> 
> My Windows Mobile phone has IPv6 and I have been able to
> access the IPv6 test website - if it works in a backwards
> country like South Africa it's gotta work in America and the
> UK!!!
>  
> > > Does the mobile client need to periodically
> notify the server about
> > its IP?
> 
> No and yes. As I said this should be handled by your
> operator's NAT: test the system and find out (connect to a
> XMPP server and go on a road trip). If it isn't you should
> definitely raise a stink.
> 
> Yes in terms that, primarily, if your public IP (i.e. one
> of your operator's IP addresses) changes chances are you are
> going to get clean disconnected. If this happens your client
> should reconnect automatically - and as a side effect of
> this the server gets your new IP.
> 
> > 
> > --
> > Fabio Forno, Ph.D.
> > Bluendo srl http://www.bluendo.com
> > jabber id: ff at jabber.bluendo.com
> > _______________________________________________
> > JDev mailing list
> > Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> > Info: http://mail.jabber.org/mailman/listinfo/jdev
> > Unsubscribe: JDev-unsubscribe at jabber.org
> > _______________________________________________
> _______________________________________________
> JDev mailing list
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________
> 


      Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/



From stpeter at stpeter.im  Thu Apr  9 09:41:22 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 09 Apr 2009 08:41:22 -0600
Subject: [jdev] Using XMPP to talk to a mobile client
In-Reply-To: <907698.28410.qm@web95414.mail.in2.yahoo.com>
References: <907698.28410.qm@web95414.mail.in2.yahoo.com>
Message-ID: <49DE0912.4030405@stpeter.im>

On 4/9/09 5:20 AM, Mridul Muralidharan wrote:
> 
> Just to mention, BOSH does not have any same client IP
> requirement/restriction.
> 
> And unlike tcp binding of xmpp - where session is terminated if
> disconnected, BOSH does handle disconnects in its design.
> 
> The only requirements would be -
> 
> a) ability of the client to connect back before the session/idle
> timeout. 

And that's part of XEP-0198. Updated version today. :)

> b) BOSH gateway not going down. 
> c) BOSH client not going down.
> 
> b and c are mentioned - so that the session state (rid, etc) is not
> lost.

Sure, if the client or server dies then state will (probably) be lost.
On the server side, people do some creative things here for high
availability / fail-over.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090409/5f740341/attachment-0003.bin>

From mridulm80 at yahoo.com  Thu Apr  9 11:33:25 2009
From: mridulm80 at yahoo.com (Mridul Muralidharan)
Date: Thu, 9 Apr 2009 22:03:25 +0530 (IST)
Subject: [jdev] Using XMPP to talk to a mobile client
Message-ID: <579761.84324.qm@web95414.mail.in2.yahoo.com>




--- On Thu, 9/4/09, Peter Saint-Andre <stpeter at stpeter.im> wrote:

> From: Peter Saint-Andre <stpeter at stpeter.im>
> Subject: Re: [jdev] Using XMPP to talk to a mobile client
> To: "Jabber/XMPP software development list" <jdev at jabber.org>
> Date: Thursday, 9 April, 2009, 8:11 PM
> On 4/9/09 5:20 AM, Mridul
> Muralidharan wrote:
> > 
> > Just to mention, BOSH does not have any same client
> IP
> > requirement/restriction.
> > 
> > And unlike tcp binding of xmpp - where session is
> terminated if
> > disconnected, BOSH does handle disconnects in its
> design..
> > 
> > The only requirements would be -
> > 
> > a) ability of the client to connect back before the
> session/idle
> > timeout. 
> 
> And that's part of XEP-0198. Updated version today. :)


Had not gone over it before, looks quite interesting - will add to my reading list ...


> 
> > b) BOSH gateway not going down. 
> > c) BOSH client not going down.
> > 
> > b and c are mentioned - so that the session state
> (rid, etc) is not
> > lost.
> 
> Sure, if the client or server dies then state will
> (probably) be lost.
> On the server side, people do some creative things here for
> high
> availability / fail-over.


Yes, I am thinking of something along those lines.
Will ping you about some queries regarding this and how it relates to stream resumption later on btw :-)

Thanks,
Mridul

> 
> Peter
> 
> -- 
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> -----Inline Attachment Follows-----
> 
> _______________________________________________
> JDev mailing list
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________
> 


      Share files, take polls, and make new friends - all under one roof. Go to http://in.promos.yahoo.com/groups/



From gnauck at ag-software.de  Thu Apr  9 12:41:48 2009
From: gnauck at ag-software.de (Alexander Gnauck)
Date: Thu, 09 Apr 2009 19:41:48 +0200
Subject: [jdev] Using XMPP to talk to a mobile client
In-Reply-To: <907698.28410.qm@web95414.mail.in2.yahoo.com>
References: <907698.28410.qm@web95414.mail.in2.yahoo.com>
Message-ID: <grlc0r$nl9$1@ger.gmane.org>

Mridul Muralidharan wrote:
> 
> 
> Just to mention, BOSH does not have any same client IP requirement/restriction.
> 
> And unlike tcp binding of xmpp - where session is terminated if disconnected, BOSH does handle disconnects in its design.
> 
> The only requirements would be -
> 
> a) ability of the client to connect back before the session/idle timeout.
> b) BOSH gateway not going down.
> c) BOSH client not going down.
> 
> b and c are mentioned - so that the session state (rid, etc) is not lost.

I have a much better experience with sockets on Mobile devices than with 
BOSH. Of course this also depends how reliable you Mobile network is, 
but in Europe its very good, and sockets works very well.

Regards,
Alex
--
Alexander Gnauck
http://www.ag-software.de
xmpp:gnauck at jabber.org



From fabio.forno at gmail.com  Thu Apr  9 14:04:48 2009
From: fabio.forno at gmail.com (Fabio Forno)
Date: Thu, 9 Apr 2009 21:04:48 +0200
Subject: [jdev] Using XMPP to talk to a mobile client
In-Reply-To: <grlc0r$nl9$1@ger.gmane.org>
References: <907698.28410.qm@web95414.mail.in2.yahoo.com>
	<grlc0r$nl9$1@ger.gmane.org>
Message-ID: <2fd53c3a0904091204r54beb404v7b331fd31a0ca227@mail.gmail.com>

On Thu, Apr 9, 2009 at 7:41 PM, Alexander Gnauck <gnauck at ag-software.de> wrote:
>
> I have a much better experience with sockets on Mobile devices than with
> BOSH. Of course this also depends how reliable you Mobile network is,
> but in Europe its very good, and sockets works very well.

Just for curisioty: bosh using the phone HTTP apis or implementing the
whole HTTP requests ?

-- 
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: ff at jabber.bluendo.com


From elghinn at free.fr  Fri Apr 10 00:05:38 2009
From: elghinn at free.fr (=?ISO-8859-15?Q?Ana=EBl_Verrier?=)
Date: Fri, 10 Apr 2009 07:05:38 +0200
Subject: [jdev] xmppony 0.1 is released!
Message-ID: <49DED3A2.1030608@free.fr>

Hi,

I'm thrilled to announce the release of xmppony 0.1.

xmppony is an XMPP library released under GNU GPLv3. It's a fork of xmpppy, 
which was in turn a fork of jabber.py.

Why a fork? Because xmpppy was almost dead in the last 2 years. Because there 
are so many things which do not suit me (like the lack of PEP 8-compliance, the 
lack of file transfer support, the coding style, the hierarchy of the code, the 
"plugin" system, the simulation of heritage, etc.).


This first release is a drop-in replacement for xmpppy, with some bugs fixed and 
file transfer added, but next releases will swap a lot more things around.


Download xmppony 0.1:
http://xmppony.last-exile.org/sources/xmppony-0.1.tar.bz2

SVN repository:
http://svn.last-exile.org/xmppony/

Browse SVN repository:
http://trac.last-exile.org/xmppony/browser

Website:
http://xmppony.last-exile.org/

Jabber room:
last-exile at muc.last-exile.org


Enjoy the release.


--
Ana?l Verrier
xmpp:elghinn at last-exile.org
GPG: 1024D/65B95D84


From norman at rasmussen.co.za  Fri Apr 10 04:46:47 2009
From: norman at rasmussen.co.za (Norman Rasmussen)
Date: Fri, 10 Apr 2009 11:46:47 +0200
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <49DED3A2.1030608@free.fr>
References: <49DED3A2.1030608@free.fr>
Message-ID: <5b698f5a0904100246t3a8f569dja688cb2f88f4d7a8@mail.gmail.com>

On Fri, Apr 10, 2009 at 7:05 AM, Ana?l Verrier <elghinn at free.fr> wrote:

> Why a fork? Because xmpppy was almost dead in the last 2 years. Because
> there
> are so many things which do not suit me (like the lack of PEP 8-compliance,
> the
> lack of file transfer support, the coding style, the hierarchy of the code,
> the
> "plugin" system, the simulation of heritage, etc.).
>

As one of the co-maintainers of xmpp.py, why is this the first time i've
heard of this?  Alexey has recently contacted me to say that he's got time
to work on xmpp.py fixing bugs, etc, and was due to release 0.5rc1 soon.

I have not yet reviewed the differences, but would you be interested in
feeding back your changes to xmpp.py?

-- 
- Norman Rasmussen
- Email: norman at rasmussen.co.za
- Home page: http://norman.rasmussen.co.za/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090410/135510b0/attachment-0003.htm>

From steve-e at h3c.de  Fri Apr 10 06:30:48 2009
From: steve-e at h3c.de (Stephan Erb)
Date: Fri, 10 Apr 2009 13:30:48 +0200
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <49DED3A2.1030608@free.fr>
References: <49DED3A2.1030608@free.fr>
Message-ID: <1239363048.5108.6.camel@localhost.localdomain>

Hey,

Gajim has forked xmpppy as well. I guess the main difference is a switch
to non-blocking sockets and the implementation of BOSH.

Maybe there is a chance here to streamline all those different efforts.

Best,
steve-e


On Fri, 2009-04-10 at 07:05 +0200, Ana?l Verrier wrote:
> Hi,
> 
> I'm thrilled to announce the release of xmppony 0.1.
> 
> xmppony is an XMPP library released under GNU GPLv3. It's a fork of xmpppy, 
> which was in turn a fork of jabber.py.
> 
> Why a fork? Because xmpppy was almost dead in the last 2 years. Because there 
> are so many things which do not suit me (like the lack of PEP 8-compliance, the 
> lack of file transfer support, the coding style, the hierarchy of the code, the 
> "plugin" system, the simulation of heritage, etc.).
> 
> 
> This first release is a drop-in replacement for xmpppy, with some bugs fixed and 
> file transfer added, but next releases will swap a lot more things around.
> 
> 
> Download xmppony 0.1:
> http://xmppony.last-exile.org/sources/xmppony-0.1.tar.bz2
> 
> SVN repository:
> http://svn.last-exile.org/xmppony/
> 
> Browse SVN repository:
> http://trac.last-exile.org/xmppony/browser
> 
> Website:
> http://xmppony.last-exile.org/
> 
> Jabber room:
> last-exile at muc.last-exile.org
> 
> 
> Enjoy the release.
> 
> 
> --
> Ana?l Verrier
> xmpp:elghinn at last-exile.org
> GPG: 1024D/65B95D84
> _______________________________________________
> JDev mailing list
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________


From asterix at lagaule.org  Fri Apr 10 06:40:13 2009
From: asterix at lagaule.org (Yann Leboulanger)
Date: Fri, 10 Apr 2009 13:40:13 +0200
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <1239363048.5108.6.camel@localhost.localdomain>
References: <49DED3A2.1030608@free.fr>
	<1239363048.5108.6.camel@localhost.localdomain>
Message-ID: <49DF301D.6070907@lagaule.org>

Stephan Erb a ?crit :
> Hey,
> 
> Gajim has forked xmpppy as well. I guess the main difference is a switch
> to non-blocking sockets and the implementation of BOSH.
> 
> Maybe there is a chance here to streamline all those different efforts.
> 
> Best,
> steve-e

That would be awsome, but I think the diff between Gajim fork and xmpppy is:

-*
+*

We re-arranged all files recently. So it will be a lot of work.


From wolf.heiner at googlemail.com  Fri Apr 10 07:26:47 2009
From: wolf.heiner at googlemail.com (Heiner Wolf)
Date: Fri, 10 Apr 2009 14:26:47 +0200
Subject: [jdev] jabber disk ?
In-Reply-To: <200903222325.n2MNPGCE017257@zogzog.maillard.mobi>
References: <200903222325.n2MNPGCE017257@zogzog.maillard.mobi>
Message-ID: <5f303cb80904100526i24671281tda272b751bfe3055@mail.gmail.com>

Hi,

Sometimes I think, that XMPP-iq-get/result does the same as
HTTP-request/response only better, because the client stays connected
and the server network does the routing including again persistent
managed connections. Beyond that, the entire RSS feed mechanism would
be much better in XMPP as pubsub. Twitter API and clients are the
worst of all. While RSS clients poll every hour, Twitter clients
HTTP-poll every minute.

To put it in other words: XMPP style two way messaging can emulate
HTTP style request/response easily. But HTTP has a hard time to
emulate two way messaging or notifications.

Would be interesting to put an XMPP transport under a Web browser and
let the XMPP server do the HTTP gateway until content servers support
XMPP natively.

Won't be easy to replace the entire infrastructure, though :-)

So, to answer your question: You might concentrate on gatewaying. Then
you can use much of the existing infrastructure. E.g. by building a
XMPP-WEBDAV gateway. WEBDAV servers provide all document management
you need for Web sites. Only thing missing to use it from the XMPP
client is a gateway. The gateway as a XMPP server component would
translate WEBDAV requests in XMPP-get/set to HTTP. Basically a
WEBDAV/XMPP to WEBDAV/HTTP gateway. What do you think?

Best
hw

On Mon, Mar 23, 2009 at 1:25 AM, Xavier Maillard <xma at gnu.org> wrote:
> Hi,
>
> I am writting a text editor with the aim to publish
> notes/articles/whatever over XMPP. I have all the basic editor
> stuff working and now has come the time to choose how to
> effectively "publish" these texts.
>
> My goal behind this, is to have access to my notes anywhere at
> anytime. I am not sure what the best method I should choose to
> store all this stuff. I know there were tries to have webdav over
> XMPP, I know there is pubsub (which has my preference) ?and
> lately I felt upon something called "jabdisk". I am looking for
> information about the later.
>
> OTOH, if you have any idea on a global storage strategy for my
> client, feel free to share them :)
>
> My main interest in writing this software is to be able to run a
> "jabber site" (aka a website) totally via XMPP and particulary a
> "XMPP wiki".
>
> Regards,
>
> ? ? ? ?Xavier
> --
> http://www.gnu.org
> http://www.april.org
> http://www.lolica.org
> _______________________________________________
> JDev mailing list
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________
>



-- 
Dr. Heiner Wolf
wolf.heiner at gmail.com
www.wolfspelz.de
www.virtual-presence.org


From simon at buddycloud.com  Fri Apr 10 08:11:11 2009
From: simon at buddycloud.com (Simon Tennant)
Date: Fri, 10 Apr 2009 15:11:11 +0200
Subject: [jdev] Using XMPP to talk to a mobile client
In-Reply-To: <grlc0r$nl9$1@ger.gmane.org>
References: <907698.28410.qm@web95414.mail.in2.yahoo.com>
	<grlc0r$nl9$1@ger.gmane.org>
Message-ID: <49DF456F.3080400@buddycloud.com>

Mobile is tricky: you fire off a stanza just as you enter a tunnel with
no coverage and your client is none the wiser as to whether the stanza
actually made it to the server. Indeed your GPRS or 3G connection may
even stay connected.

We have also had good success on the mobile by using sockets rather than
BOSH in the Buddycloud client. 

There are a couple of tricks that we used to ensure we loose no messages:

    * On mobile networks the phone client may be pushing off messages
      into a socket that has lost cellular coverage.  If you have a
      large sliding window on the TCP layer, these messages are lost.
      Twiddling your TCP stack can help keep the number of packets
      between ACKs low.
    * We have worked around these by using message archiving (XEP-0136)
      and re-requesting messages slightly before the device lost connection.
    * "warm starting".  In a bouncy environment having to pull down the
      roster, PEP and pub-sub subscriptions each time will get
      expensive.  If a session can be recovered, recover, and keep on going.

The real solution will be implementing XEP-0198: Stream Management and
managing acknowledged stanzas at the application layer. This is
something that we plan on implementing to handle the unpredictable
mobile environment.

S.

Alexander Gnauck wrote:
> Mridul Muralidharan wrote:
>   
>> Just to mention, BOSH does not have any same client IP requirement/restriction.
>>
>> And unlike tcp binding of xmpp - where session is terminated if disconnected, BOSH does handle disconnects in its design.
>>
>> The only requirements would be -
>>
>> a) ability of the client to connect back before the session/idle timeout.
>> b) BOSH gateway not going down.
>> c) BOSH client not going down.
>>
>> b and c are mentioned - so that the session state (rid, etc) is not lost.
>>     
>
> I have a much better experience with sockets on Mobile devices than with 
> BOSH. Of course this also depends how reliable you Mobile network is, 
> but in Europe its very good, and sockets works very well.
>
> Regards,
> Alex
> --
> Alexander Gnauck
> http://www.ag-software.de
> xmpp:gnauck at jabber.org
>
> _______________________________________________
> JDev mailing list
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________
>
>
>   


-- 
Simon Tennant
Buddycloud
uk: +44 20 7043 6756               de: +49 89 420 955 854  
uk: +44 78 5335 6047               de: +49 17 8545 0880
email and xmpp: simon at buddycloud.com
http://buddycloud.com



From whateley at gmail.com  Fri Apr 10 10:49:25 2009
From: whateley at gmail.com (Brendan Taylor)
Date: Fri, 10 Apr 2009 09:49:25 -0600
Subject: [jdev] jabber disk ?
In-Reply-To: <200903222325.n2MNPGCE017257@zogzog.maillard.mobi>
References: <200903222325.n2MNPGCE017257@zogzog.maillard.mobi>
Message-ID: <20090410154925.GB23928@nyarlathotep>

On Mon, Mar 23, 2009 at 12:25:16AM +0100, Xavier Maillard wrote:
> OTOH, if you have any idea on a global storage strategy for my
> client, feel free to share them :)
> 
> My main interest in writing this software is to be able to run a
> "jabber site" (aka a website) totally via XMPP and particulary a
> "XMPP wiki".

It seems to me that for this kind of project it would make sense to base
your protocol on the Atom Publishing Protocol. That gives you a pretty
well-supported representation for your pages, and as Heiner said it would
be pretty easy to imitate the HTTP requests in XMPP. It would be
interesting to see what aspects of AtomPub could be done differently
when XMPP is being used instead of HTTP.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090410/d459e71c/attachment-0003.pgp>

From elghinn at free.fr  Fri Apr 10 14:47:25 2009
From: elghinn at free.fr (=?UTF-8?B?QW5hw6tsIFZlcnJpZXI=?=)
Date: Fri, 10 Apr 2009 21:47:25 +0200
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <5b698f5a0904100246t3a8f569dja688cb2f88f4d7a8@mail.gmail.com>
References: <49DED3A2.1030608@free.fr>
	<5b698f5a0904100246t3a8f569dja688cb2f88f4d7a8@mail.gmail.com>
Message-ID: <49DFA24D.8060707@free.fr>

Norman Rasmussen a ?crit :
> On Fri, Apr 10, 2009 at 7:05 AM, Ana?l Verrier <elghinn at free.fr> wrote:
> 
>> Why a fork? Because xmpppy was almost dead in the last 2 years. Because
>> there
>> are so many things which do not suit me (like the lack of PEP 8-compliance,
>> the
>> lack of file transfer support, the coding style, the hierarchy of the code,
>> the
>> "plugin" system, the simulation of heritage, etc.).
>>
> 
> As one of the co-maintainers of xmpp.py, why is this the first time i've
> heard of this? Alexey has recently contacted me to say that he's got time
> to work on xmpp.py fixing bugs, etc, and was due to release 0.5rc1 soon.

1) I have submited a patch[1] 11 months ago.
But my patch was waiting without responses. It was not alone[2][3][4][5].

2) No clues the project was alive.
See 1).
There was only few commits in the last year, and even less if we don't count 
those which do not touch with the code (like [6] and [7])

3) We didn?t announce anything before we had something to announce.
I do not have as a practice to announce a project prematurely.

4) Misfortunate timing.
I have forked the 03/26/09 as you can see on the project timeline[8]. And 
released it today. When I have forked, Alexey had not improved yet with the 
code. Thus I had already made things before he is not put at it.

Yes, when I make the release, that made already 4-5 days that there had been of 
the activity on the repository. But I only saw it when the release was done.

But does that really change something?

5) Gr?goire Menuel proposed a patch[9] for the file transfer.
But you refused it. And whatever is the reason, at the current hour we can not 
still make a file transfer with xmpppy.

I find important to have the file transfer, in particular for a bot.

For example, Erwan Briand, the author of CodingTeam[10] and administrator of 
codingteam.net, envisages to make a robot by which one will be able to download 
the versions of the projects directly since jabber without having to go on the 
site. And it is only one example among so many others.

[1] 
http://sourceforge.net/tracker/?func=detail&aid=1961193&group_id=97081&atid=616917
[2] 
http://sourceforge.net/tracker/?func=detail&aid=1962375&group_id=97081&atid=616917
[3]
http://sourceforge.net/tracker/?func=detail&aid=1780774&group_id=97081&atid=616917
[4]
http://sourceforge.net/tracker/?func=detail&aid=1929415&group_id=97081&atid=616915
[5]
http://sourceforge.net/tracker/?func=detail&aid=1949483&group_id=97081&atid=616915

[6] 
http://xmpppy.cvs.sourceforge.net/viewvc/xmpppy/xmpppy/xmpp/protocol.py?r1=1.58&r2=1.59
[7] 
http://xmpppy.cvs.sourceforge.net/viewvc/xmpppy/xmpppy/xmpp/protocol.py?r1=1.57&r2=1.58

[8] http://trac.last-exile.org/xmppony/changeset/1

[9]
http://sourceforge.net/mailarchive/forum.php?thread_name=1122740972.42ebaaec4a799%40webmail.insa-lyon.fr&forum_name=xmpppy-devel

[10] http://codingteam.codingteam.net/


> 
> I have not yet reviewed the differences, but would you be interested in
> feeding back your changes to xmpp.py?
> 

Our fixes are and will be free software, you?ll be able to take them back if you 
want. However, I have the intention to change quite a lot of things: revamp 
simplexmp, replace debug with standard logging, get rid of fake inheritance, 
etc. Are these ground-breaking changes suitable for incorporation in xmpppy?



--
Ana?l Verrier
xmpp:elghinn at last-exile.org
GPG: 1024D/65B95D84



From norman at rasmussen.co.za  Fri Apr 10 16:23:52 2009
From: norman at rasmussen.co.za (Norman Rasmussen)
Date: Fri, 10 Apr 2009 23:23:52 +0200
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <49DFA24D.8060707@free.fr>
References: <49DED3A2.1030608@free.fr>
	<5b698f5a0904100246t3a8f569dja688cb2f88f4d7a8@mail.gmail.com>
	<49DFA24D.8060707@free.fr>
Message-ID: <5b698f5a0904101423k50f9f500m57ca90888cd76423@mail.gmail.com>

On Fri, Apr 10, 2009 at 9:47 PM, Ana?l Verrier <elghinn at free.fr> wrote:
> 1) I have submited a patch[1] 11 months ago.
> But my patch was waiting without responses. It was not alone[2][3][4][5].

Unfortunately I haven't been looking at the bug tracker on sf.net, I
haven't had time to more than apply patches sent to the mailing list.

> 2) No clues the project was alive.

the xmpp.py mailing list has about 5 or so threads per month, of which
I read each and every message.  If this thread gets anymore detailed,
I think we should perhaps redirect it to that list so that we don't
overwhelm the jdev list with our plans to rule python-xmpp
development.

> 3) We didn?t announce anything before we had something to announce.
> I do not have as a practice to announce a project prematurely.

sounds good

> 4) Misfortunate timing.
> I have forked the 03/26/09 as you can see on the project timeline[8]. And
> released it today. When I have forked, Alexey had not improved yet with the
> code. Thus I had already made things before he is not put at it.
> Yes, when I make the release, that made already 4-5 days that there had been of
> the activity on the repository. But I only saw it when the release was done.

true, misfortunate timing, yes.

> 5) Gr?goire Menuel proposed a patch[9] for the file transfer.
> But you refused it. And whatever is the reason, at the current hour we can not
> still make a file transfer with xmpppy.

wow, this was from before I started on xmpp.py.  Do you know that
there were no less than 3 requests for file transfer code in the last
6 months.  If I'd known I would have at least looked at the patch.

> Our fixes are and will be free software, you?ll be able to take them back if you
> want. However, I have the intention to change quite a lot of things: revamp
> simplexmp, replace debug with standard logging, get rid of fake inheritance,
> etc. Are these ground-breaking changes suitable for incorporation in xmpppy?

as far as I'm concerned:
 - simplexml is ugly and should be thrown away.  something like the
standard python xml.dom and xml.sax (maybe xml.dom.pulldom) would be
more than enough
 - agree on the debugging
 - not sure what you mean about the fake inheritance - do you mean the
plugging?

Much of the code of xmpp.py was written by Alexey _before_ python had
support for all this stuff in it's internal libraries.  I've had to
deal with being able to run the transports on Python 2.2.  I think
Alexey did a fantastic job with what he had to work with when he wrote
the library.  Unfortunately (as it happens to all of us), he was
unable to dedicate as much time as he would have wanted to maintaining
the library.

Moving forwards I would like to see:
 - true asynchronous code - Gajim team did this about a year ago.
They added non-blocking calls for almost everything that used to
block.  Support for asyncore would be great, because this is another
python built-in library.
 - cleaner separation of concerns - the Gajim team have started on
this.  The client should not care if the server connection is TCP or
TLS or SSL or BOSH or Magic-transport-method-5.
 - the library should continue to support client and transport
connections.  adhoc commands should get client-side (consumer) support
(currently only server-side (producer) is supported).
 - file transfer would be fantastic, would you support all 5 methods?
(si, ibb, oob, socks5, jingle)

-- 
- Norman Rasmussen
 - Email: norman at rasmussen.co.za
 - Home page: http://norman.rasmussen.co.za/


From elghinn at free.fr  Fri Apr 10 16:48:09 2009
From: elghinn at free.fr (=?ISO-8859-15?Q?Ana=EBl_Verrier?=)
Date: Fri, 10 Apr 2009 23:48:09 +0200
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <1239363048.5108.6.camel@localhost.localdomain>
References: <49DED3A2.1030608@free.fr>
	<1239363048.5108.6.camel@localhost.localdomain>
Message-ID: <49DFBE99.3090103@free.fr>

Stephan Erb a ?crit :
> Hey,
> 
> Gajim has forked xmpppy as well. I guess the main difference is a switch
> to non-blocking sockets and the implementation of BOSH.
> 
> Maybe there is a chance here to streamline all those different efforts.
> 
> Best,
> steve-e
> 
> 
Gajim uses non-blocking sockets to not have to use threads. I do not think only 
it is necessary to neglect the use of threads just to not have to be bored with, 
especially at the hour of the processors multi-cores.

Moreover as Yann said, the fork of Gajim does not really have anything any more 
to do with the xmpppy origin. So to reinstate my work in the fork of Gajim is 
impossible (of as much more than I do not intend to pass by non-blocking sockets).

Of elsewhere, it seems that the fork of Gajim is integrated now too much into 
Gajim, as if that had always done only one with Gajim.

So, that would involve large change in Gajim to set out again on the use of a 
third library.

To finish, I would say that I really intend to go in another direction that is 
currently taken by xmpppy. Although this release seems to bring nothing more 
than some corrections of bugs, a better respect of the pep8, and the file 
transfer, it is necessary to keep with the spirit that it is there to 
officialize the project.

As I said to Norman Rasmussen, I do not have any problem against the fact that 
it reinstates my modifications in xmpppy. But very sincerely I doubt that all my 
modifications are reinstated in xmpppy.

And although Alexey very recently recovered above, what says to us that he will 
have time to leave the 0.5 and to continue thereafter? Who says to us that there 
will not be another 2 year hole in the development of xmpppy?

I do not seek to blame him. He has his life. And I thank him for the work which 
he already carried out until now. Only for the reasons already evoked, I felt 
the need to fork xmpppy.

Future will tell whether my project is a mere waste of time or whether it really 
has its place. While keeping in mind that I have nothing against a future 
bringing together of the two projects, here and now I prefer coding and going ahead.

--
Ana?l Verrier
xmpp:elghinn at last-exile.org
GPG: 1024D/65B95D84


From xma at gnu.org  Sat Apr 11 13:25:02 2009
From: xma at gnu.org (Xavier Maillard)
Date: Sat, 11 Apr 2009 20:25:02 +0200
Subject: [jdev] jabber disk ?
In-Reply-To: message from Peter Saint-Andre on Mon, 06 Apr 2009 22:20:45 -0600
Message-ID: <200904111825.n3BIP2X7015823@zogzog.maillard.mobi>

Hi,

   On 3/22/09 5:25 PM, Xavier Maillard wrote:
   > 
   > I am writting a text editor with the aim to publish
   > notes/articles/whatever over XMPP. I have all the basic editor
   > stuff working and now has come the time to choose how to
   > effectively "publish" these texts.
   > 
   > My goal behind this, is to have access to my notes anywhere at
   > anytime. I am not sure what the best method I should choose to
   > store all this stuff. I know there were tries to have webdav over
   > XMPP, I know there is pubsub (which has my preference)  and
   > lately I felt upon something called "jabdisk". I am looking for
   > information about the later.
   > 
   > OTOH, if you have any idea on a global storage strategy for my
   > client, feel free to share them :)
   > 
   > My main interest in writing this software is to be able to run a
   > "jabber site" (aka a website) totally via XMPP and particulary a
   > "XMPP wiki".

   Why? Isn't that what HTTP is for?

Why ?

Some reasons:

1. for fun
2. to just have something cool to demo at my next LUG meeting
3. I am more likely to use XMPP services than any other service
(I am even connected 24/7 with my jid via my mobile)
4. I'd like to test/implement XEPs in real life

Enough ?

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org


From jonathan.dickinson at k2.com  Tue Apr 14 07:08:06 2009
From: jonathan.dickinson at k2.com (Jonathan Dickinson)
Date: Tue, 14 Apr 2009 14:08:06 +0200
Subject: [jdev] Digest URIs for XMPP
Message-ID: <A790BE8D83ECC3469047C2E344EABE61027C685F7D52@zamail01.k2workflow.com>

I am busy doing the SASL lib for my server/client (almost completely finished with DIGEST-MD5). I was just wondering what the common practice is for digest-uris with varying ports. Some people use them as follows:

Port 80:
http/www.foo.com
Port 8080:
http/www.foo.com

Where others:

Port 80:
http/www.foo.com
Port 8080:
http/www.foo.com:8080

So which one is in common use in the XMPP world?

Also where the connect server is different I would assume the following would apply (I am just confirming what I have read):

xmpp/talk.google.com/google.com

Or even:

xmpp/talk.google.com/gmail.com

Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090414/46e71d6a/attachment-0003.htm>

From stpeter at stpeter.im  Tue Apr 14 11:19:21 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 14 Apr 2009 10:19:21 -0600
Subject: [jdev] Digest URIs for XMPP
In-Reply-To: <A790BE8D83ECC3469047C2E344EABE61027C685F7D52@zamail01.k2workflow.com>
References: <A790BE8D83ECC3469047C2E344EABE61027C685F7D52@zamail01.k2workflow.com>
Message-ID: <49E4B789.40800@stpeter.im>

On 4/14/09 6:08 AM, Jonathan Dickinson wrote:
> I am busy doing the SASL lib for my server/client (almost completely
> finished with DIGEST-MD5). I was just wondering what the common practice
> is for digest-uris with varying ports. Some people use them as follows:
> 
>  
> 
> Port 80:
> 
> http/www.foo.com
> 
> Port 8080:
> 
> http/www.foo.com
> 
>  
> 
> Where others:
> 
>  
> 
> Port 80:
> 
> http/www.foo.com
> 
> Port 8080:
> 
> http/www.foo.com:8080
> 
>  
> 
> So which one is in common use in the XMPP world?

Isn't this what SRV records are for?

> Also where the connect server is different I would assume the following
> would apply (I am just confirming what I have read):
> 
>  
> 
> xmpp/talk.google.com/google.com
> 
>  
> 
> Or even:
> 
>  
> 
> xmpp/talk.google.com/gmail.com

As you know from RFC 2831, the format is:

serv-type "/" host [ "/" serv-name ]

The serv-type is always xmpp for us.

The host is the machine you connect to (or discover via SRV).

The serv-name is the name used by the client to discover the machine.

In the case of Google Talk, you look up gmail.com (or googlemail.com or
whatever) and discover things like this:

$ dig +short -t SRV _xmpp-client._tcp.gmail.com
20 0 5222 talk4.l.google.com.
5 0 5222 talk.l.google.com.
20 0 5222 talk1.l.google.com.
20 0 5222 talk2.l.google.com.
20 0 5222 talk3.l.google.com.

So I think that the resulting digest-uri would be of this form:

xmpp/talk.l.google.com/gmail.com

But I freely admit that this might be subject to interpretation, as so
many things are when it comes to the DIGEST-MD5 SASL mechanism. :(

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090414/8a53d1c3/attachment-0003.bin>

From stpeter at stpeter.im  Tue Apr 14 17:09:55 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 14 Apr 2009 16:09:55 -0600
Subject: [jdev] MXM #2
Message-ID: <49E509B3.2090308@stpeter.im>

On March 12 and again today, we held a "Monthly XMPP Meeting":

http://logs.jabber.org/jdev at conference.jabber.org/2009-03-12.html#15:01:15

http://logs.jabber.org/jdev at conference.jabber.org/2009-04-14.html#14:06:45

I know it's a bit backwards, but I'm going to report on today's meeting
first because it's fresh in my mind (and sorry about not yet publishing
minutes from the first meeting). There was no set agenda, but we talked
about the following topics:

1. Last Call for XEP-0232 (Software Information)

http://xmpp.org/extensions/xep-0232.html

http://logs.jabber.org/jdev at conference.jabber.org/2009-04-14.html#14:10:41

Points:

- Is this a misuse of service discovery?

- Will this make entity capability caches less useful because they will
be too large to search easily?

- Does it make more sense to publish this information via PEP using the
XEP-0092 format?

The XMPP Council will vote on XEP-0232 at its next meeting (April 22).
More feedback is welcome before then.

2. Last Call for XEP-0237 (Roster Versioning)

http://xmpp.org/extensions/xep-0237.html

http://logs.jabber.org/jdev at conference.jabber.org/2009-04-14.html#14:23:19

General agreement that this is in good shape. There are still a few edge
cases to figure out, especially the empty roster case.

3. Last Calls for the core Jingle specs

http://logs.jabber.org/jdev at conference.jabber.org/2009-04-14.html#14:29:52

No real discussion here. Most people seemed to think that these are
ready for Draft.

4. Pubsub/PEP implementations

http://logs.jabber.org/jdev at conference.jabber.org/2009-04-14.html#14:37:41

Consensus that we need more interop testing among idavoll, ejabberd,
Openfire, Tigase, etc. Perhaps make this a focus at the next XMPP Summit.

5. XEP-0198 (Stream Management)

http://xmpp.org/extensions/xep-0198.html

http://logs.jabber.org/jdev at conference.jabber.org/2009-04-14.html#14:53:43

People like this. Let's go forth and implement. :)

6. Bidirectional s2s

http://logs.jabber.org/jdev at conference.jabber.org/2009-04-14.html#15:00:34

We decided that we need a dedicated discussion session about s2s fixes
and improvements (dialback, multiplexing domains over a given stream via
TLS/SASL/dialback/whatever, etc.). We agreed to make that the focus of
the next Monthly XMPP Meeting, tentatively scheduled for May 5.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090414/696ff0c2/attachment-0003.bin>

From Kurt.Zeilenga at Isode.com  Tue Apr 14 22:30:36 2009
From: Kurt.Zeilenga at Isode.com (Kurt Zeilenga)
Date: Tue, 14 Apr 2009 20:30:36 -0700
Subject: [jdev] Digest URIs for XMPP
In-Reply-To: <49E4B789.40800@stpeter.im>
References: <A790BE8D83ECC3469047C2E344EABE61027C685F7D52@zamail01.k2workflow.com>
	<49E4B789.40800@stpeter.im>
Message-ID: <452495EA-3CB7-40BD-A773-B4B144397FC9@Isode.com>

I think clients ought to simply assert xmpp/host where host is  
whatever string the user specified to connect to.

But more importantly is what should the server do.  RFC 2831 says:
    Servers SHOULD check that the supplied value is correct. This will
    detect accidental connection to the incorrect server. It is also so
    that clients will be trained to provide values that will work with
    implementations that use a shared back-end authentication service
    that can provide server authentication.

I suggest instead:
    Servers SHOULD ignore that the supplied value.  The check
    was intended to detect that client did not accidentally
    connect to the incorrect server.  Performing the check will far more
    likely lead to disconnecting of clients which did connect to the
    correct server than disconnecting clients which accidentally  
connected
    to an incorrect server.

Such checks tend to make the application services brittle.   (Consider  
the implications of forward and reverse NAT devices, transparent (to  
the client and server) tunneling, etc.)

-- Kurt



From dave at cridland.net  Wed Apr 15 04:54:49 2009
From: dave at cridland.net (Dave Cridland)
Date: Wed, 15 Apr 2009 10:54:49 +0100
Subject: [jdev] [Standards] MXM #2
In-Reply-To: <49E509B3.2090308@stpeter.im>
References: <49E509B3.2090308@stpeter.im>
Message-ID: <7088.1239789289.390264@puncture>

On Tue Apr 14 23:09:55 2009, Peter Saint-Andre wrote:
> The XMPP Council will vote on XEP-0232 at its next meeting (April  
> 22).
> More feedback is welcome before then.
> 
> 
As usual, you're welcome to turn up to the Council meetings, and  
express your views there. (But for the next meeting, you'll need to  
bring cake.)

> We decided that we need a dedicated discussion session about s2s  
> fixes
> and improvements (dialback, multiplexing domains over a given  
> stream via
> TLS/SASL/dialback/whatever, etc.). We agreed to make that the focus  
> of
> the next Monthly XMPP Meeting, tentatively scheduled for May 5.

Matthew Wild and I have agreed to write "something" up in terms of a  
strawman proposal we can batter about.

Feel free to write one too - I'll endeavour to send something to the  
list before then.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade


From jonathan.dickinson at k2.com  Wed Apr 15 07:52:13 2009
From: jonathan.dickinson at k2.com (Jonathan Dickinson)
Date: Wed, 15 Apr 2009 14:52:13 +0200
Subject: [jdev] SASL (again)
Message-ID: <A790BE8D83ECC3469047C2E344EABE61027CE3C683B4@zamail01.k2workflow.com>

Hi All,

RFC 4616 implies that it is possible to store a digest for CRAM-MD5 in the database (just above 3. Pseudo-Code). From what I can tell you need to store a plain-text password (at best the XORed passwords, which is pointless).

A CRAM digest is created as follows:

MD5(
   (K XOR opad),
   MD5(
      (K XOR ipad),
      timestamp
      )
   )

Where 'timestamp' is variant ("<" num "." num "@" domain ">"). Am I missing some mathematical nuance, or is RFC 4616 misleading?

Jonathan





From dave at cridland.net  Wed Apr 15 09:57:53 2009
From: dave at cridland.net (Dave Cridland)
Date: Wed, 15 Apr 2009 15:57:53 +0100
Subject: [jdev] SASL (again)
In-Reply-To: <A790BE8D83ECC3469047C2E344EABE61027CE3C683B4@zamail01.k2workflow.com>
References: <A790BE8D83ECC3469047C2E344EABE61027CE3C683B4@zamail01.k2workflow.com>
Message-ID: <7088.1239807473.358000@puncture>

On Wed Apr 15 13:52:13 2009, Jonathan Dickinson wrote:
> Hi All,
> 
> RFC 4616 implies that it is possible to store a digest for CRAM-MD5  
> in the database (just above 3. Pseudo-Code). From what I can tell  
> you need to store a plain-text password (at best the XORed  
> passwords, which is pointless).
> 
> 
In all practical senses, yes, but it's possible to store a  
digest-like entity.

> A CRAM digest is created as follows:
> 
> MD5(
>    (K XOR opad),
>    MD5(
>       (K XOR ipad),
>       timestamp
>       )
>    )

Where, in turn, K is derived from, in C-like pseudocode:

K = (strlen(password) > L) ? MD5(password) : password + ('\0' * (L -  
strlen(password)))
Where L is the block length of the hash algorithm, or 128 bits in the  
case of MD5.

So K might be reasonable stuff, or it might be the password.

But that's not what CRAM-MD5 suggests storing - they suggest storing  
the intemediate hash states - effectively an MD5 internal array pair  
pre-primed with (K ^ opad) and (K ^ ipad). This is considerably more  
secure than "just a XOR", as K is at least one block-size, and  
therefore it's roughly the same, I think, as an MD5 to extract the  
password, which is to say it requires a brute-force attack, made  
harder because the combination of the two hashes means that you need  
to find a solution to both.

Still, in general, you just call an HMAC-MD5 function in some  
library, and, in rare cases, you write the HMAC wrapper over a stock  
MD5 - either way, the best you have is the XOR products, which aren't  
nearly as good unless your users really like long passwords.

Moreover, by doing this, you're forced into storing a seperate secret  
for DIGEST-MD5, so in most cases, server implementors have two modes  
- storing plaintext passwords, for flexiblility in mechanisms, and  
storing hashed passwords, which essentially restricts to PLAIN and -  
hopefully soon - SCRAM.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade


From elghinn at free.fr  Wed Apr 15 19:08:18 2009
From: elghinn at free.fr (=?UTF-8?B?QW5hw6tsIFZlcnJpZXI=?=)
Date: Thu, 16 Apr 2009 02:08:18 +0200
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <5b698f5a0904101423k50f9f500m57ca90888cd76423@mail.gmail.com>
References: <49DED3A2.1030608@free.fr>	<5b698f5a0904100246t3a8f569dja688cb2f88f4d7a8@mail.gmail.com>	<49DFA24D.8060707@free.fr>
	<5b698f5a0904101423k50f9f500m57ca90888cd76423@mail.gmail.com>
Message-ID: <49E676F2.3030804@free.fr>

Norman Rasmussen a ?crit :
>> Our fixes are and will be free software, you?ll be able to take them back if you
>> want. However, I have the intention to change quite a lot of things: revamp
>> simplexmp, replace debug with standard logging, get rid of fake inheritance,
>> etc. Are these ground-breaking changes suitable for incorporation in xmpppy?
> 
> as far as I'm concerned:
>  - simplexml is ugly and should be thrown away.  something like the
> standard python xml.dom and xml.sax (maybe xml.dom.pulldom) would be
> more than enough
I don't think that removing simplexml would be a good thing. simplexml is simple
(Captain Obvious agrees), and having a simple API to make Python objets from an
XML stream (thanks to expat) and serialize them back (thanks to __str__) seems
useful to me. I prefer cleaning simplexml than using DOM. I think we don?t need
such a complicated interface to handle stanzas.

>  - not sure what you mean about the fake inheritance - do you mean the
> plugging?
Yes, the plugin system and the horror[1] in client.py (CommonClient is derivated
in Client and Component, but its contructor does different things according to
the one call it (Client.__init__ or Component.__init__)). And other stuff like
this one.

[1] http://trac.last-exile.org/xmppony/browser/trunk/xmppony/client.py?rev=30#L119

> 
> Much of the code of xmpp.py was written by Alexey _before_ python had
> support for all this stuff in it's internal libraries.  I've had to
> deal with being able to run the transports on Python 2.2.  I think
> Alexey did a fantastic job with what he had to work with when he wrote
> the library.  Unfortunately (as it happens to all of us), he was
> unable to dedicate as much time as he would have wanted to maintaining
> the library.
> 
As I already said to steve-e, I thank him for his job and I don't blame him: he
has his life.

> Moving forwards I would like to see:
>  - true asynchronous code - Gajim team did this about a year ago.
> They added non-blocking calls for almost everything that used to
> block.  Support for asyncore would be great, because this is another
> python built-in library.
I don't understand why people do not like threads :'(
threading is a standard Python module too.

>  - cleaner separation of concerns - the Gajim team have started on
> this.  The client should not care if the server connection is TCP or
> TLS or SSL or BOSH or Magic-transport-method-5.
That sounds good.

I want Magic-transport-method-5 \o/

>  - the library should continue to support client and transport
> connections.  adhoc commands should get client-side (consumer) support
> (currently only server-side (producer) is supported).
Adhoc commands, pep, and other cool stuff are on my roadmap for v0.3.


>  - file transfer would be fantastic, would you support all 5 methods?
> (si, ibb, oob, socks5, jingle)
> 
For now, xmppony supports si, socks5 and ibb. With emacs-jabber, I can already
send and receive files from a bot based on xmppony.
Jingle support would be great, but I didn't plan to touch it now (except if
someone sends me a patch).


As I said in previous mail, for v0.2, I plan to revamp simplexml, replace debug
with standard logging and get rid of fake inheritance. But I also take a look to
rfcs and xeps. Because they evolved since the code was written. For example, I
found 2 problems in omega's patch (which was written 4-5 years ago). I also plan
to make some unit tests.

The base must be cleanest possible before going further!


-- 
Ana?l Verrier
xmpp:elghinn at last-exile.org
GPG: 1024D/65B95D84





From asterix at lagaule.org  Thu Apr 16 02:21:32 2009
From: asterix at lagaule.org (Yann Leboulanger)
Date: Thu, 16 Apr 2009 09:21:32 +0200
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <49E676F2.3030804@free.fr>
References: <49DED3A2.1030608@free.fr>	<5b698f5a0904100246t3a8f569dja688cb2f88f4d7a8@mail.gmail.com>	<49DFA24D.8060707@free.fr>	<5b698f5a0904101423k50f9f500m57ca90888cd76423@mail.gmail.com>
	<49E676F2.3030804@free.fr>
Message-ID: <49E6DC7C.6080209@lagaule.org>

Ana?l Verrier wrote:

> As I said in previous mail, for v0.2, I plan to revamp simplexml, replace debug
> with standard logging and get rid of fake inheritance. But I also take a look to
> rfcs and xeps. Because they evolved since the code was written. For example, I
> found 2 problems in omega's patch (which was written 4-5 years ago). I also plan
> to make some unit tests.

We already have logging system based on logging module in Gajim
We have unittest for some xmpppy things. Have a look at test folder.
What about zeroconf?

Really sad all that work is duplicated :/

-- 
Yann


From norman at rasmussen.co.za  Thu Apr 16 03:12:34 2009
From: norman at rasmussen.co.za (Norman Rasmussen)
Date: Thu, 16 Apr 2009 10:12:34 +0200
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <49E676F2.3030804@free.fr>
References: <49DED3A2.1030608@free.fr>
	<5b698f5a0904100246t3a8f569dja688cb2f88f4d7a8@mail.gmail.com>
	<49DFA24D.8060707@free.fr>
	<5b698f5a0904101423k50f9f500m57ca90888cd76423@mail.gmail.com>
	<49E676F2.3030804@free.fr>
Message-ID: <5b698f5a0904160112k76801109k50c6d7f7e2394c41@mail.gmail.com>

On Thu, Apr 16, 2009 at 2:08 AM, Ana?l Verrier <elghinn at free.fr> wrote:
>> ?- true asynchronous code - Gajim team did this about a year ago.
>> They added non-blocking calls for almost everything that used to
>> block. ?Support for asyncore would be great, because this is another
>> python built-in library.
> I don't understand why people do not like threads :'(
> threading is a standard Python module too.

because you can't spin off one thread for each connection on a server :-)

(on a client it's reasonable, because you may only have 5 to 10
threads, but one a server with 100+ threads, it starts to go haywire)

-- 
- Norman Rasmussen
 - Email: norman at rasmussen.co.za
 - Home page: http://norman.rasmussen.co.za/


From dave at cridland.net  Thu Apr 16 03:43:38 2009
From: dave at cridland.net (Dave Cridland)
Date: Thu, 16 Apr 2009 09:43:38 +0100
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <49DFBE99.3090103@free.fr>
References: <49DED3A2.1030608@free.fr>
	<1239363048.5108.6.camel@localhost.localdomain>
	<49DFBE99.3090103@free.fr>
Message-ID: <12297.1239871418.665567@puncture>

On Fri Apr 10 22:48:09 2009, Ana?l Verrier wrote:
> Gajim uses non-blocking sockets to not have to use threads. I do  
> not think only
> it is necessary to neglect the use of threads just to not have to  
> be bored with,
> especially at the hour of the processors multi-cores.

I think you want to be careful about what you're implying, there.  
Gajim's architecture - using a single non-blocking thread - is  
perfectly fine, as you certainly don't want or need multithreading  
there.

You do need threads for high-volume systems, but you want them  
scaling by core, not by connection.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade


From dmeyer at tzi.de  Thu Apr 16 07:04:43 2009
From: dmeyer at tzi.de (Dirk Meyer)
Date: Thu, 16 Apr 2009 14:04:43 +0200
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <49E676F2.3030804@free.fr> (=?iso-8859-1?Q?=22Ana=EBl?=
	Verrier"'s message of "Thu\, 16 Apr 2009 02\:08\:18 +0200")
References: <49DED3A2.1030608@free.fr>
	<5b698f5a0904100246t3a8f569dja688cb2f88f4d7a8@mail.gmail.com>
	<49DFA24D.8060707@free.fr>
	<5b698f5a0904101423k50f9f500m57ca90888cd76423@mail.gmail.com>
	<49E676F2.3030804@free.fr>
Message-ID: <87skk8x0ro.fsf@phex.sachmittel.de>

Ana?l Verrier wrote:
> I don't understand why people do not like threads :'(

Because you get race conditions

>From one of your other mails:
> Gajim uses non-blocking sockets to not have to use threads. I do not
> think only it is necessary to neglect the use of threads just to not
> have to be bored with, especially at the hour of the processors
> multi-cores.

Python does not benefit from multi-cores when using threads. The
interpreter lock makes multi-core useless unless you are in a C module
and release the lock. Gajim will not benefit from threads at all.


Dirk

-- 
Those that make the rules don't play the game!


From dave at cridland.net  Thu Apr 16 07:17:46 2009
From: dave at cridland.net (Dave Cridland)
Date: Thu, 16 Apr 2009 13:17:46 +0100
Subject: [jdev] xmppony 0.1 is released!
In-Reply-To: <87skk8x0ro.fsf@phex.sachmittel.de>
References: <49DED3A2.1030608@free.fr>
	<5b698f5a0904100246t3a8f569dja688cb2f88f4d7a8@mail.gmail.com>
	<49DFA24D.8060707@free.fr>
	<5b698f5a0904101423k50f9f500m57ca90888cd76423@mail.gmail.com>
	<49E676F2.3030804@free.fr> <87skk8x0ro.fsf@phex.sachmittel.de>
Message-ID: <12297.1239884266.048964@puncture>

On Thu Apr 16 13:04:43 2009, Dirk Meyer wrote:
> Ana?l Verrier wrote:
> > I don't understand why people do not like threads :'(
> 
> Because you get race conditions
> 
> 
And if you're in a race, and you have a loose thread, it can get  
caught on a bush an unravel your whole jumper.

Sorry, realised I hadn't made any bad jokes on this list in ages,  
although that does look like a disturbingly good analogy.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade


From merwok at netwok.org  Thu Apr 16 21:29:15 2009
From: merwok at netwok.org (=?utf-8?Q? =C3=89ric=20Araujo =20)
Date: Fri, 17 Apr 2009 04:29:15 +0200
Subject: [jdev] xmppony 0.1 is released!
Message-ID: <54216.1239935355@netwok.org>

Hello jdev


Let me first introduce myself, as a newcomer on this list. I am a Python
programmer and Jabber enthusiast. I hang around on some of the same chatrooms
as elghinn. I?ve known of the fork project since its beginning, made some minor
patches, and found the name. Note that my understanding of XMPP is incomplete:
I?ve read user documentation and some presentations about the protocol, but not
the specifications, therefore I cannot debate stuff related to the protocol
itself, but I do have strong opinions about Python code and some requests about
the features and API of the library. I speak on my own behalf, with bits from
discussions with elghinn.


[Yann Leboulanger]
> We already have logging system based on logging module in Gajim
I wanted to do this part of the fork, so I?ll make sure to look at Gajim?s
solution first. Thanks.

> We have unittest for some xmpppy things. Have a look at test folder.
I?m sure elghinn will look at that, especially since Gajim is under GPLv3 too.

> What about zeroconf?
Depends on the aims of xmppony. If it should be the Python library for clients,
bots and scripts, it would be in. If it aims at being the Python library for
scripts and bots (elghinn?s original idea), that would be overkill. elghinn
won?t write zeroconf support, but patches will probably be accepted. Or perhaps
not, if there?s no long-term support with the patches.

> Really sad all that work is duplicated :/
Well, this discussion is a starting point for cooperation.


[Norman Rasmussen]
>> I don't understand why people do not like threads :'(
> because you can't spin off one thread for each connection on a server :-)
elghinn does not intend to use Python for a server, seeing there are really
good C/C++ libraries out there.


[Dirk Meyer]
>> I don't understand why people do not like threads :'(
> Because you get race conditions
We believe locks can prevent them.


[Dave Cridland]
>> Gajim uses non-blocking sockets to not have to use threads. I do not think
>> only it is necessary to neglect the use of threads just to not have to be
>> bored with, especially at the hour of the processors multi-cores.
> I think you want to be careful about what you're implying, there. Gajim's
> architecture - using a single non-blocking thread - is  perfectly fine, as
> you certainly don't want or need multithreading there.
>
> You do need threads for high-volume systems, but you want them scaling by
> core, not by connection.
I?m not well-versed enough in parallel processing to make an answer here.

And thank you for the joke :]


Cheers,

?ric Araujo



From stpeter at stpeter.im  Tue Apr 21 17:27:26 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 21 Apr 2009 16:27:26 -0600
Subject: [jdev] gaming@xmpp.org
Message-ID: <49EE484E.6050105@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've created a new list for discussions related to gaming applications
of XMPP technologies. Subscribe here:

http://mail.jabber.org/mailman/listinfo/gaming

mailto:gaming-subscribe at xmpp.org

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknuSE4ACgkQNL8k5A2w/vzovwCcCwZR92qZi5MgTFfJoDlslHVu
ZmgAnR0hMr8bH3hBL7LEZI3ShR/WzT3j
=9IxI
-----END PGP SIGNATURE-----


From bf_lists at brainlounge.de  Wed Apr 22 03:36:57 2009
From: bf_lists at brainlounge.de (Bernd Fondermann)
Date: Wed, 22 Apr 2009 10:36:57 +0200
Subject: [jdev] [ANN] Apache Vysper and GSoC project
Message-ID: <49EED729.9040507@brainlounge.de>

Hi,

Apache Vysper (pronounce 'whisper', source[1], docs[2]) is an
ASL-licensed[4] open source XMPP implementation in Java currently under
development at the Apache Software Foundation.

After some years at Apache Labs, Vysper is now a sub-project of Apache
MINA[3] and development will hopefully take up speed there.

Vysper has seen no release yet, is not ready for production, and docs
are still sparse.

Additionally, I'm happy to announce that we can welcome Michael Jakl as
a Google Summer of Code student this year. He will implement PubSub for
Vysper. So XMPP is not completely lost on SoC :-)

The ASF is an open community not very different in mindset from the XSF.
So everybody here is invited to use, participate and contribute to
Apache Vysper.

Thanks for listening,

  Bernd

XMPP: berndf at jabber.org
MAIL: berndf at apache.org

[1] http://svn.apache.org/repos/asf/mina/sandbox/vysper
[2] http://cwiki.apache.org/confluence/display/labs/vysper
[3] http://mina.apache.org
[4] http://svn.apache.org/repos/asf/mina/sandbox/vysper/LICENSE.txt





From sh at defuze.org  Wed Apr 22 05:40:02 2009
From: sh at defuze.org (Sylvain Hellegouarch)
Date: Wed, 22 Apr 2009 12:40:02 +0200
Subject: [jdev] [ANN] Apache Vysper and GSoC project
In-Reply-To: <49EED729.9040507@brainlounge.de>
References: <49EED729.9040507@brainlounge.de>
Message-ID: <49EEF402.3080604@defuze.org>

Bernd Fondermann a ?crit :
> Hi,
>
> Apache Vysper (pronounce 'whisper', source[1], docs[2]) is an
> ASL-licensed[4] open source XMPP implementation in Java currently under
> development at the Apache Software Foundation.
>
> After some years at Apache Labs, Vysper is now a sub-project of Apache
> MINA[3] and development will hopefully take up speed there.
>
> Vysper has seen no release yet, is not ready for production, and docs
> are still sparse.
>
> Additionally, I'm happy to announce that we can welcome Michael Jakl as
> a Google Summer of Code student this year. He will implement PubSub for
> Vysper. So XMPP is not completely lost on SoC :-)
>
> The ASF is an open community not very different in mindset from the XSF.
> So everybody here is invited to use, participate and contribute to
> Apache Vysper.
>
> Thanks for listening,
>
>   Bernd
>
> XMPP: berndf at jabber.org
> MAIL: berndf at apache.org
>
> [1] http://svn.apache.org/repos/asf/mina/sandbox/vysper
> [2] http://cwiki.apache.org/confluence/display/labs/vysper
> [3] http://mina.apache.org
> [4] http://svn.apache.org/repos/asf/mina/sandbox/vysper/LICENSE.txt
>
>   

Nice.

However, how many XMPP server written in Java do we need? Why not 
helping on Tigase for instance? I'm puzzled since XMPP servers are hard 
to write, we had OpenFire then Tigase now Vysper.

Anyhow, all the best for it :)

- Sylvain


From bf_lists at brainlounge.de  Wed Apr 22 06:12:28 2009
From: bf_lists at brainlounge.de (Bernd Fondermann)
Date: Wed, 22 Apr 2009 13:12:28 +0200
Subject: [jdev] [ANN] Apache Vysper and GSoC project
In-Reply-To: <49EEF402.3080604@defuze.org>
References: <49EED729.9040507@brainlounge.de> <49EEF402.3080604@defuze.org>
Message-ID: <49EEFB9C.7070402@brainlounge.de>

Sylvain Hellegouarch wrote:
> Bernd Fondermann a ?crit :
>> Hi,
>>
>> Apache Vysper (pronounce 'whisper', source[1], docs[2]) is an
>> ASL-licensed[4] open source XMPP implementation in Java currently under
>> development at the Apache Software Foundation.
>>
>> After some years at Apache Labs, Vysper is now a sub-project of Apache
>> MINA[3] and development will hopefully take up speed there.
>>
>> Vysper has seen no release yet, is not ready for production, and docs
>> are still sparse.
>>
>> Additionally, I'm happy to announce that we can welcome Michael Jakl as
>> a Google Summer of Code student this year. He will implement PubSub for
>> Vysper. So XMPP is not completely lost on SoC :-)
>>
>> The ASF is an open community not very different in mindset from the XSF.
>> So everybody here is invited to use, participate and contribute to
>> Apache Vysper.
>>
>> Thanks for listening,
>>
>>   Bernd
>>
>> XMPP: berndf at jabber.org
>> MAIL: berndf at apache.org
>>
>> [1] http://svn.apache.org/repos/asf/mina/sandbox/vysper
>> [2] http://cwiki.apache.org/confluence/display/labs/vysper
>> [3] http://mina.apache.org
>> [4] http://svn.apache.org/repos/asf/mina/sandbox/vysper/LICENSE.txt
>>
>>   
> 
> Nice.
> 
> However, how many XMPP server written in Java do we need? Why not
> helping on Tigase for instance? I'm puzzled since XMPP servers are hard
> to write, we had OpenFire then Tigase now Vysper.

Thanks for the question, it is very valid.
You are right, the XMPP server ecosystem is very diverse (in terms of
implementation language). Yet, most of the implementations are GPL'ed.

I prefer BSD/ASL-licensed software - not neccessarily as a user, but
when writing code. (The GPL is a very good and a strong license, and so
are BSD-type licenses. Every class has its weaknesses and strengths. I
have not the slightest interest in discussion superiority of any of
them.) It's intended providing a choice here for XMPP server users.
Implementation-wise we are still far away from being that choice.

You could still argue that I should have tried to persuaed some
implementation to move to ASL, but (if they'd had agreed) that would
have taken all the fun of writing a XMPP server from scratch.

> Anyhow, all the best for it :)

Thanks! :-)

  Bernd


From sh at defuze.org  Wed Apr 22 06:30:51 2009
From: sh at defuze.org (Sylvain Hellegouarch)
Date: Wed, 22 Apr 2009 13:30:51 +0200 (CEST)
Subject: [jdev] [ANN] Apache Vysper and GSoC project
In-Reply-To: <49EEFB9C.7070402@brainlounge.de>
References: <49EED729.9040507@brainlounge.de> <49EEF402.3080604@defuze.org>
	<49EEFB9C.7070402@brainlounge.de>
Message-ID: <53147.193.253.216.132.1240399851.squirrel@mail1.webfaction.com>


> I prefer BSD/ASL-licensed software - not neccessarily as a user, but
> when writing code. (The GPL is a very good and a strong license, and so
> are BSD-type licenses. Every class has its weaknesses and strengths. I
> have not the slightest interest in discussion superiority of any of
> them.) It's intended providing a choice here for XMPP server users.
> Implementation-wise we are still far away from being that choice.

That's a valid point and I share your views on the licensing subject.

>
> You could still argue that I should have tried to persuaed some
> implementation to move to ASL, but (if they'd had agreed) that would
> have taken all the fun of writing a XMPP server from scratch.

True. Like I wrote my own XMPP lib in Python when I could've tried to help
an existing one. Fun is the first motivational aspect of most OSS projects
:)

- Sylvain


-- 
Sylvain Hellegouarch
http://www.defuze.org


From jonathan.dickinson at k2.com  Thu Apr 23 04:02:22 2009
From: jonathan.dickinson at k2.com (Jonathan Dickinson)
Date: Thu, 23 Apr 2009 11:02:22 +0200
Subject: [jdev] [ANN] Apache Vysper and GSoC project
In-Reply-To: <49EEF402.3080604@defuze.org>
References: <49EED729.9040507@brainlounge.de> <49EEF402.3080604@defuze.org>
Message-ID: <A790BE8D83ECC3469047C2E344EABE61027E35F7C3D6@zamail01.k2workflow.com>

> -----Original Message-----
> From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] On
> Behalf Of Sylvain Hellegouarch
> Sent: 22 April 2009 12:40 PM
> To: Jabber/XMPP software development list
> Subject: Re: [jdev] [ANN] Apache Vysper and GSoC project
> 
> [...] I'm puzzled since XMPP servers are hard
> to write, we had OpenFire then Tigase now Vysper.
> 

Amen. However, writing an XMPP server is a pleasure at the same time! It will be interesting to see what they come up with (it will be pretty hard to follow in Tigase' steps).

> Anyhow, all the best for it :)
> 
> - Sylvain
> _______________________________________________
> JDev mailing list
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________


From will at netmindz.net  Wed Apr 29 15:11:06 2009
From: will at netmindz.net (Will Tatam)
Date: Wed, 29 Apr 2009 21:11:06 +0100
Subject: [jdev] Flash conference
Message-ID: <49F8B45A.3030200@netmindz.net>

Anyone recommend any pre-existing flash xmpp conference clients ? I'm 
looking at add a flash chatroom to a site

I know I could build by own using XIFF but as i've not done and flash in 
about 3 years a pre-existing one would be preferable

Will


From dave at cridland.net  Wed Apr 29 15:20:36 2009
From: dave at cridland.net (Dave Cridland)
Date: Wed, 29 Apr 2009 21:20:36 +0100
Subject: [jdev] Flash conference
In-Reply-To: <49F8B45A.3030200@netmindz.net>
References: <49F8B45A.3030200@netmindz.net>
Message-ID: <15169.1241036436.511912@puncture>

On Wed Apr 29 21:11:06 2009, Will Tatam wrote:
> Anyone recommend any pre-existing flash xmpp conference clients ?  
> I'm looking at add a flash chatroom to a site
> 
> I know I could build by own using XIFF but as i've not done and  
> flash in about 3 years a pre-existing one would be preferable

Why Flash? Will Speeqe not do?

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade


From nathanfritz at gmail.com  Wed Apr 29 16:22:22 2009
From: nathanfritz at gmail.com (Nathan Fritz)
Date: Wed, 29 Apr 2009 14:22:22 -0700
Subject: [jdev] Flash conference
In-Reply-To: <15169.1241036436.511912@puncture>
References: <49F8B45A.3030200@netmindz.net> <15169.1241036436.511912@puncture>
Message-ID: <182eea400904291422k3ebed760o597074fec6db1983@mail.gmail.com>

On Wed, Apr 29, 2009 at 1:20 PM, Dave Cridland <dave at cridland.net> wrote:

> On Wed Apr 29 21:11:06 2009, Will Tatam wrote:
>
>> Anyone recommend any pre-existing flash xmpp conference clients ? I'm
>> looking at add a flash chatroom to a site
>
>
>> I know I could build by own using XIFF but as i've not done and flash in
>> about 3 years a pre-existing one would be preferable
>>
>
My Flash lib includes a MUC example.  Seesmic-AS3-XMPP aka TwhiX.


>
> Why Flash? Will Speeqe not do?
>
> Dave.
> --
> Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net<xmpp%3Adwd at dave.cridland.net>
>  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
>  - http://dave.cridland.net/
> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
>
> _______________________________________________
> JDev mailing list
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090429/783d9780/attachment-0003.htm>

From will at netmindz.net  Wed Apr 29 17:04:51 2009
From: will at netmindz.net (Will Tatam)
Date: Wed, 29 Apr 2009 23:04:51 +0100
Subject: [jdev] (no subject)
In-Reply-To: <15169.1241036436.511912@puncture>
References: <49F8B45A.3030200@netmindz.net> <15169.1241036436.511912@puncture>
Message-ID: <49F8CF03.10007@netmindz.net>

On 29/04/09 21:20, Dave Cridland wrote:
> On Wed Apr 29 21:11:06 2009, Will Tatam wrote:
>> Anyone recommend any pre-existing flash xmpp conference clients ? I'm
>> looking at add a flash chatroom to a site
>>
>> I know I could build by own using XIFF but as i've not done and flash
>> in about 3 years a pre-existing one would be preferable
>
> Why Flash? Will Speeqe not do?
>
> Dave.

It has a whole stack of server dependencies, flash would just be client 
side plus XMPP server of choice, not python, django, postgresql ... etc


From koski.tuomas at gmail.com  Wed Apr 29 17:41:26 2009
From: koski.tuomas at gmail.com (Tuomas Koski)
Date: Thu, 30 Apr 2009 00:41:26 +0200
Subject: [jdev] Example PubSub -service to publish BBC World News
Message-ID: <1d142be30904291541p63221e61kd621e3718334f972@mail.gmail.com>

Hi guys and gals,

I'm kind of new to XMPP techniques and I'm a person who only learns by
"doing it my self" so:

I did a example PubSub service that publishes all the BBC World News
as they are published by BBC. There are 2 ways to subscribe to the
service:

1) add bbc-news at xmpp.lobstermonster.org to your XMPP roster
 OR
2) find "bbc_news" -node at pubsub.xmpp.lobstermonster.org and do the
needed PubSub subscriptions

The first option is more user friendly since you just need to add the
contact to you roster, and when you want to unsubscribe, you just
remove the bbc-news -users from your contacts. And this feature should
be provided by almost all the XMPP clients rather than easy to use
PubSub -functionalism.

The other difference in this service is that when a new item is
published to the node, user bbc-news at xmpp.lobstermonster.org will send
you the item also as "clear message". This is done so that the service
is usable even with gMail's client.

I also wrote a small story about it on my web site:
http://www.lobstermonster.org/post/xmpp-pubsub-service-to-publish-bbc-world-news

If you have any ideas how the service could work better, don't
hesitate to yell out loud! And if you want me to add your favorite RSS
feed to be able to be subscribed like this, I can do that too.


Cheers,
--
tuomas

ps. sorry if someone get's this mail twice, I send it also to the
pubsub -mailing list.


From dave at cridland.net  Thu Apr 30 03:19:09 2009
From: dave at cridland.net (Dave Cridland)
Date: Thu, 30 Apr 2009 09:19:09 +0100
Subject: [jdev] (no subject)
In-Reply-To: <49F8CF03.10007@netmindz.net>
References: <49F8B45A.3030200@netmindz.net>
	<15169.1241036436.511912@puncture> <49F8CF03.10007@netmindz.net>
Message-ID: <20772.1241079549.140220@puncture>

On Wed Apr 29 23:04:51 2009, Will Tatam wrote:
> It has a whole stack of server dependencies, flash would just be  
> client side plus XMPP server of choice, not python, django,  
> postgresql ... etc

Ah, I thought Speeqe just needed BOSH.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade


From sdk at disktree.net  Thu Apr 30 04:57:45 2009
From: sdk at disktree.net (tong)
Date: Thu, 30 Apr 2009 11:57:45 +0200
Subject: [jdev] Flash conference
In-Reply-To: <49F8B45A.3030200@netmindz.net>
References: <49F8B45A.3030200@netmindz.net>
Message-ID: <1241085465.23015.17.camel@mini>

On Wed, 2009-04-29 at 21:11 +0100, Will Tatam wrote:
> Anyone recommend any pre-existing flash xmpp conference clients ? I'm 
> looking at add a flash chatroom to a site
> 
> I know I could build by own using XIFF but as i've not done and flash in 
> about 3 years a pre-existing one would be preferable
> 

our (haxe) hxmpp library supports flash9+ and muchat too.
since haxe 2.03 you can also output SWCs for reuse with AS3.

latest source is here:
http://disktree.spektral.at/git/?a=summary&p=hxmpp

i am not aware of a 'ready to go' muc flash-component.

best.tong


> _______________________________________________
> JDev mailing list
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________



From stpeter at stpeter.im  Thu Apr 30 11:23:27 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 30 Apr 2009 10:23:27 -0600
Subject: [jdev] [Fwd: [Standards] Call for Experience: XEP-0138 (Stream
	Compression)]
Message-ID: <49F9D07F.1070604@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

FYI.

- -------- Original Message --------
Subject: [Standards] Call for Experience: XEP-0138 (Stream Compression)
Date: Thu, 30 Apr 2009 10:13:27 -0600
From: Peter Saint-Andre <stpeter at stpeter.im>
Reply-To: XMPP Standards <standards at xmpp.org>
To: XMPP Extension Discussion List <standards at xmpp.org>

In its meeting yesterday, the XMPP Council agreed to issue a "Call for
Experience" regarding XEP-0138 (Stream Compression), in preparation for
perhaps advancing this specification from Draft to Final in the XSF's
standards process. To help the Council decide whether this XEP is ready
to advance to a status of Final, the Council would like to gather the
following information:

1. Who has implemented XEP-0138? Please note that the protocol must be
implemented in at least two separate codebases (and preferably more).

2. Have developers experienced any problems with the protocol as defined
in XEP-0138? If so, please describe the problems and, if possible,
suggested solutions.

3. Is the text of XEP-0138 clear and unambiguous? Are more examples
necessary? Is the conformance language (MAY/SHOULD/MUST) appropriate?
Have developers found the text confusing at all? Please describe any
suggestions you have for improving the text.

If you have any comments about advancing XEP-0138 from Draft to Final in
the XSF's standards process, please provide them by the close of
business on Friday, May 22, 2009. After the Call for Experience, this
XEP might undergo revisions to address feedback received, after which it
will be presented to the XMPP Council for voting to a status of Final.

You can review the XEP here:

http://www.xmpp.org/extensions/xep-0138.html

Please send all feedback to the standards at xmpp.org list.

Thanks!

Peter

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn50H8ACgkQNL8k5A2w/vyMaACg5XwXGo1FslHvqO26oRqigDAG
81sAoOFI4uuIkfZtWoB4FZ90tk/LnAey
=9ga6
-----END PGP SIGNATURE-----


From stpeter at stpeter.im  Thu Apr 30 11:23:43 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 30 Apr 2009 10:23:43 -0600
Subject: [jdev] [Fwd: [Standards] Call for Experience: XEP-0199 (XMPP Ping)]
Message-ID: <49F9D08F.20502@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

FYI.

- -------- Original Message --------
Subject: [Standards] Call for Experience: XEP-0199 (XMPP Ping)
Date: Thu, 30 Apr 2009 10:16:40 -0600
From: Peter Saint-Andre <stpeter at stpeter.im>
Reply-To: XMPP Standards <standards at xmpp.org>
To: XMPP Extension Discussion List <standards at xmpp.org>

In its meeting yesterday, the XMPP Council agreed to issue a "Call for
Experience" regarding XEP-0199 (XMPP Ping), in preparation for perhaps
advancing this specification from Draft to Final in the XSF's standards
process. To help the Council decide whether this XEP is ready to advance
to a status of Final, the Council would like to gather the following
information:

1. Who has implemented XEP-0199? Please note that the protocol must be
implemented in at least two separate codebases (and preferably more).

2. Have developers experienced any problems with the protocol as defined
in XEP-0199? If so, please describe the problems and, if possible,
suggested solutions.

3. Is the text of XEP-0199 clear and unambiguous? Are more examples
needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? Have
developers found the text confusing at all? Please describe any
suggestions you have for improving the text.

If you have any comments about advancing XEP-0199 from Draft to Final,
please provide them by the close of business on Friday, May 22, 2009.
After the Call for Experience, this XEP might undergo revisions to
address feedback received, after which it will be presented to the XMPP
Council for voting to a status of Final.

You can review the XEP here:

http://www.xmpp.org/extensions/xep-0199.html

Please send all feedback to the standards at xmpp.org list.

Thanks!

Peter


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn50I8ACgkQNL8k5A2w/vx9fwCg54KWg3I1LQn+I5N+MCrJn9C1
b3QAn3YSYO5mA0xFnuiUiOqElnoRF42x
=jRup
-----END PGP SIGNATURE-----


From stpeter at stpeter.im  Thu Apr 30 12:13:21 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 30 Apr 2009 11:13:21 -0600
Subject: [jdev] server RFP for jabber.org IM service
Message-ID: <49F9DC31.30604@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The jabber.org admin team has decided to issue an RFP for the XMPP
server software that runs the jabber.org IM service. Full information is
available here:

http://www.jabber.org/index.php/2009/04/server-rfp/

Please let me know if you have any questions.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn53DEACgkQNL8k5A2w/vybYwCg95KrzeBp39c8zkDWLjnfqoBl
nT8Anis9q4SOCFdP20C01UFOk4ygbp6h
=XU1+
-----END PGP SIGNATURE-----