functionality and will
be releasing the updates at the same download link. If you have any
comments/questions please let me know.
Stephen Pendleton
mov Software
___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev
I recommend newbies and non-newbies to check out Disney's Jabber
Go-Messenger for Windows. It is on par with MSN Messenger and is very stable
and easy to use.
___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev
It seems that there has been a slight protocol change on the jabber.org
development server. In particular, when registering on a gateway it used to
be required that a key was exchanged between the client and the server.
Now it seems that the requirement has been dropped and clients that send the
Adrian,
SSL in the Jabber case is the same as any SSL connection.
Here is some Win32 code that you can use to establish a SSL
socket:
nt
certificate_validation_procedure (DWORD dwType, LPVOID pvArg, DWORD
dwChainLen,
LPBLOB pCertChain, DWORD dwFlags){return
SSL_ERR_OKAY;}
int
I was wondering if anyone has tried this:
I am attempting to cache the roster of the user locally (in a file) so the
roster does not need to be downloaded from the server everytime the client
connects (conserves bandwidth). This works fine, but if I attempt to add a
user to the roster, no result
Incidentally, why not just simply contribute to one of the many OS server
projects out there?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Matthew Beacher
Sent: Tuesday, February 11, 2003 8:38 AM
To: [EMAIL PROTECTED]
Subject: [JDEV] Server Problems,
Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Tijl Houtbeckers
Sent: Tuesday, February 11, 2003 12:44 PM
To: [EMAIL PROTECTED]
Subject: Re: [JDEV] Server Problems, of the lying kind.
Stephen Pendleton [EMAIL PROTECTED] wrote on 11-2-2003
17:29:10:
Incidentally, why
I am doing some work on the client side with pubsub and I have a question
about the subscription approval request that gets sent to a potential
subscriber to a node. The JEP states this:
When a Jabber entity wishes to subscribe to a node, it sends an IQ request
to the pubsub service. Depending on
]
Subject: Re: [JDEV] PubSub Subscription Requests
Stephen Pendleton wrote:
Understood. Makes sense. The reason is that in my client I am attempting
to
automatically allow people to subscribe to my node, and I am attempting to
find a robust way of parsing this node.
Why not just configure the node
Does anyone have a jabberd server with Pubsub and DISCO server running that
could be used to test various client technologies out?
Thanks,
Stephen
___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev
Why not integrate JEP-112 into JEP-80? They both deal with the same issue
(location, location, location) and use the same mechanism (pubsub). We could
just add the extra info in the tags in JEP-112 into JEP-80.
___
jdev mailing list
[EMAIL PROTECTED]
Question regarding IQ packet behavior:
If I send an IQ packet like:
iq type='get' to='[EMAIL PROTECTED]' from='[EMAIL PROTECTED]' id=''loc
xmlns='http://jabber.org/protocol/geoloc'//iq
shouldn't that get delivered to the JID [EMAIL PROTECTED], even if the server
doesn't support the GEOLOC
Hello,
I am introducing a new service that client developers may be interested
in. This service will deliver turn-by-turn routing information (similar to
MapQuest) between pairs of JID's (that have location information associated
with them by implementation of the GEOLOC JEP), or pairs of
you consider the use of UTM? and of the
universal address system http://www.nacgeo.com/
and imo the user should be able to indicate source and destinations in
different location systems.
--- Stephen Pendleton [EMAIL PROTECTED]
wrote:
Hello,
I am introducing a new service that client
This is really something that is needed, since building gateways is kind of
a mystical art. Will a gateway built with this framework work on different
Jabber server implementations?
Thanks
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Peter Saint-Andre
interesting other
things: util.c:75 dropping 503 packet iq to='[EMAIL PROTECTED]'
from='[EMAIL PROTECTED]/balcony' type='error' id='route1'error
code='503'Service Unavailable/error/iq
--- Stephen Pendleton [EMAIL PROTECTED]
wrote:
Yes, UTM would be good to have. I don't know about
the nacgeo
Here is another review of a PDA client (our PocketPC client):
http://www.pocketnow.com/index.php?a=portal_detailt=reviewsid=377
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Peter Saint-Andre
Sent: Monday, May 17, 2004 11:49 AM
To: [EMAIL PROTECTED]
Out of interest, why was this distinction (need for a full JID) made between
IQ stanzas and message stanzas in XMPP-IM?
Thanks
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Jacek Konieczny
Sent: Saturday, June 05, 2004 11:52 AM
To: [EMAIL PROTECTED]
I think this makes a lot of sense. We should eat our own dog food as much
as possible. After all, what is more applicable to a pubsub system then a
published email list that people subscribe to! Of course I also believe that
those that come up with excellent ideas should implement them too! :-)
I can offer some insight into one certification process:
I have been through the Microsoft Mobile certification for our Smartphone
and PocketPC client, and I know this process required a large infrastructure
behind it. In that case, there is a third party company doing the
certification which
I believe that the reason that client developers do not implement these
particular JEP's is because there may be no demand for them at this time in
their XMPP applications, not just because they are marked as 'experimental'.
There are JEP's that have some value to me (pubsub, sasl, geoloc, CAP,
I don't think you need an entire certification process for this. We could
simply rearrange the client list to indicate which clients support which
features. The client author(s) would need to submit this information. I
don't think mispresentation by the client authors would be an issue. Even
] On Behalf Of
Chris Mullins
Sent: Friday, June 18, 2004 3:03 PM
To: Jabber software development list
Subject: RE: [jdev] Jabber Certification Program
Stephen Pendleton Wrote:
The client author(s) would need to submit this information. I don't
think mispresentation by the client authors would
' geolevel3='zzz' geolevel2='zzz' country='USA' code='19117'/
where the geolevel* are optional. So your example will look like:
src street= '4555 Main Street ' geolevel3='Philadelphia' geolevel2='PA'
country='USA' code='19117'/
Regards,
-- Gato
Stephen Pendleton [EMAIL PROTECTED] wrote
of doing it?
Geoff.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Stephen Pendleton
Sent: 14 September 2004 18:47
To: 'Jabber software development list'
Subject: RE: [jdev] Gaim - transport
This is very cool. I would be interested in seeing
I am assuming that someone on the list owns the jabberview.com domain.
Apparently the domain name has expired. Is the domain going to be
reregisted?
Thanks
___
jdev mailing list
[EMAIL PROTECTED]
https://jabberstudio.org/mailman/listinfo/jdev
After reading over the presentation, the system looks interesting but what
are some use cases of the software? Would it be used in the same type of use
cases that J2EE is?
Thanks
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Mickael Remond
Sent:
I am currently implementing the GEOLOC JEP-0080 with the pubsub mechanism,
and I have run into an issue that may be caused by a misunderstanding on my
part.
The issue is that JEP-0080 doesn't have an explicit use-case for how an
Entity would subscribe to a particular users location information in
Out of curiosity, why doesn't the USGS or you use the CAP protocol for this?
I see that other agencies do. See http://dma.jrc.it/Services/gdas/ and
http://dma.jrc.it/services/dss/alerttools/alerttoolsxml.asp for an example
of CAP alerts of earthquake data provided by the EU.
Are you considering
I would think the bug lies at least in client a since the client adds b
to its roster even though it was not requested. In defense of the client
developer, it is a bit complicated to handle this correctly since the client
would need to remember outstanding subscription requests between runs of
After reading through the JEP-0138, I would like to submit some ideas on
this to the jdev community. As was mentioned before on the list many mobile
clients have limited processing and/or memory requirements that may preclude
the use of zlib at certain compression levels. For example, zlib
In practical use, what are the advantages of TLS/SSL with SASL DIGEST-MD5
versus TLS/SSL with SASL PLAIN authentication? DIGEST-MD5 seems to be such a
pain to have to add on the client and server sides. I can imagine this is
why Google didn't implement DIGEST-MD5. Since the stream is already
Title: Message
I
recently wrote a program to test XMPP servers for basic compliance to the IETF
XMPP RFC. When I mean "basic" I mean it only tests the
following:
1)
Does the server return "version = '1.0'" in their stream:stream
element?
2)
Does the server offer the stream:features
]; Jabber software development list
Subject: Re: [jdev] XMPP Compliance
try the servers at:
http://www.xmpp.net/
specially binaryfreedom.info I'm using jabberd 2.x
Chris
Stephen Pendleton wrote:
I recently wrote a program to test XMPP servers for basic compliance
to the IETF XMPP RFC. When I mean
Take a look at http://www.movsoftware.com/developers.htm for some Windows
Mobile compatible jabber libraries. These are all in C/C++, no Java.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Hernan Tylim
Sent: Thursday, December 01, 2005 11:04 AM
To:
Taking a look at an example zlib implementation's header file there a few
items that control the behavior of the zlib compressor/decompressor:
#define Z_NO_COMPRESSION 0
#define Z_BEST_SPEED 1
#define Z_BEST_COMPRESSION 9
#define Z_DEFAULT_COMPRESSION (-1)
/*
will send you a copy.
Thanks!
-Original Message-
From: Peter Saint-Andre [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 01, 2005 12:32 PM
To: [EMAIL PROTECTED]; Jabber software development list
Subject: Re: [jdev] Zlib compression
Stephen Pendleton wrote:
As you can see, you can
was going to be able to download basic, but instead it only listed the
Enterprise version.
thanks
On 12/1/05, Stephen Pendleton [EMAIL PROTECTED] wrote:
The Basic version of imov Messenger for the PocketPC/HandheldPC is
free (as in beer).
-Original Message-
From: [EMAIL PROTECTED
Incidentally, it seems that jabber.org includes version=1.0 but doesn't
offer SASL - at least for c2s connections.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Justin Karneges
Sent: Friday, December 30, 2005 10:46 AM
To: Jabber software development
I can also confirm that it works well: I am seeing reductions of the XML
stream of about 60%. Does Wildfire have compression for s2s connections as
well as c2s?
Stephen
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
JD Conley
Sent: Monday, January 09,
This is extremely impressive! Is it possible to set up such a system where a
user would be able to use their XMPP ID's from other domains to edit? For
example, is it possible that [EMAIL PROTECTED] could use the Bouillon
component on foo.org even though jabber.org isn't running the Bouillon
I think the point is that we should forget about proprietary systems like
Skype and implement open standards like Jingle.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Tomasz Sterna
Sent: Thursday, July 13, 2006 12:45 PM
To: Jabber software development
I am curious if anyone has any public services running that utilize the
GEOLOC JEP? More to the point, I am looking to see if we can interoperate
with other GEOLOC implementations out there.
There may be a small difference in battery savings, but since you still need
to keep an active data session going I doubt it is appreciable. I do not
think there is much of a difference between an active data session that is
transmitting and receiving application level data versus an active
Hello, I am doing some implementation of the GEOLOC XEP using pubsub and I
ran into this question during implementation:
I have a special case I want to retrieve the location of myself from the
pubsub component for initialization purposes, but I do not want to subscribe
to my location since I do
Where do you see this? I got my example from Example 66 in XEP-0060.
Thanks
-Original Message-
From: Remko Troncon [mailto:[EMAIL PROTECTED]
Sent: Monday, October 16, 2006 12:20 PM
To: [EMAIL PROTECTED]; Jabber software development list
Subject: Re: GEOLOC XEP
iq type='get'
Yes, thanks. PEP really is the way to go here ultimately. However the server
I am using doesn't implement PEP, but has Pubsub. I didn't see another
example of a 'manual' retrieval in the pubsub XEP.
-Original Message-
From: Remko Troncon [mailto:[EMAIL PROTECTED]
Sent: Monday, October
Todd, I have successfully implemented a mobile solution that may cover this use
case, however it was intended for MANET systems which did not have central
servers and not the client/server system that you are envisioning. However here
is a idea that you may consider:
Instead of keeping track
Will the ISP's allow inbound connections to these NATted addresses?
If not, that is yet another problem to solve.
...
Unfortunately, it seems that current s2s protocols will not work with
servers behind NAT. Additionally, there is a potential core problem
related to XMPP server names. If
Jeff, so you know what is the status of OASIS and the CAP protocol? Isn't that
what the USGS and NWS uses? We have a XEP for CAP alerts over XMPP:
http://www.xmpp.org/extensions/xep-0127.html
This should work for you. I've done a test implementation so the XEP works.
Thanks
Date: Fri, 18
to CAP alerts by translating the CAP info into pubsub. It would make
an excellent Google SoC project (hint, hint!)
Date: Mon, 21 Apr 2008 15:51:30 -0400 From: [EMAIL PROTECTED] To:
jdev@jabber.org Subject: Re: [jdev] resources available via XMPP...
Stephen Pendleton wrote: Jeff, so you know
Interestingly enough I ran across the iemchat site a few days ago. Out of
curiosity where do you get your feeds from now and what is the format?
Date: Mon, 21 Apr 2008 19:02:53 -0400 From: [EMAIL PROTECTED] To:
jdev@jabber.org Subject: Re: [jdev] resources available via XMPP...
Ernest Nova
Date: Mon, 26 May 2008 19:59:39 -0700 From: [EMAIL PROTECTED] To:
jdev@jabber.org Subject: [jdev] Any Clients Supporting XEP-0080 User
Location ? Are there any clients that support XEP-0080 ? Any interesting
mashups of note ?
Yes, imov Messenger does and has used XEP-0080 using pubsub
Hi, I thought I would put together a simple cookbook on how to add GEOLOC
XEP-0080 support to a client. Hopefully it will help someone else out. If
anyone sees any problems with the steps below, please let me know. BTW, I am
not sure why Step 1 is needed since Step 2 advertises the same
Thanks for the reply.
From: [EMAIL PROTECTED] To: jdev@jabber.org Date: Thu, 11 Sep 2008 16:26:44
-0600 Subject: Re: [jdev] GEOLOC Support On Sep 9, 2008, at 10:24 AM,
Stephen Pendleton wrote: Hi, I thought I would put together a simple
cookbook on how to add GEOLOC XEP-0080
You are right when we use a SHA1 hash, I'm not sure what I was thinking there.
I hope client developers start implementing this XEP. I only know two
implementations so far. If it was widespread we could implement something like
http://brightkite.com/ using XMPP!
Date: Fri, 31 Oct 2008
Date: Fri, 31 Oct 2008 09:19:25 -0600 From: [EMAIL PROTECTED] To:
jdev@jabber.org Subject: Re: [jdev] GEOLOC Support I hope client
developers start implementing this XEP. I only know two implementations so
far. Which are?
I only know of imov Messenger
Date: Fri, 31 Oct 2008 09:46:26 -0600 From: [EMAIL PROTECTED] To:
jdev@jabber.org Subject: Re: [jdev] GEOLOC Support Date: Fri, 31 Oct
2008 09:19:25 -0600 From: [EMAIL PROTECTED] To: jdev@jabber.org
Subject: Re: [jdev] GEOLOC Support I only know of imov Messenger
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?
Also, how does the component push my location to my PEP node if I am on
another server? Would this be
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
] 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 he...@buddycloud.com wrote:
Stephen Pendleton wrote:
I can't seem to get
I like this idea. Is there something that would keep you from writing the
nearby concept up as a XEP?
-Original Message-
From: jdev-boun...@jabber.org [mailto:jdev-boun...@jabber.org] On Behalf Of
Simon Tennant (Buddycloud)
Sent: Monday, March 29, 2010 12:01 PM
To: jdev@jabber.org
Imov Messenger also supports MUC for android
From: jdev-boun...@jabber.org [mailto:jdev-boun...@jabber.org] On Behalf Of
Norman Rasmussen
Sent: Tuesday, May 18, 2010 6:37 AM
To: Jabber/XMPP software development list
Subject: Re: [jdev] Android XMPP Client
Jabiru is the only one that I
-Original Message-
From: jdev-boun...@jabber.org [mailto:jdev-boun...@jabber.org] On Behalf Of
Jonathan Schleifer
Sent: Thursday, August 26, 2010 5:25 AM
To: Jabber/XMPP software development list
Subject: Re: [jdev] The future of Jabber/XMPP?
Which is already true for jabberd1 and
Lots of bugs in PEP server implementations are because the XEP itself is
written poorly. It doesn't scale: the idea of keeping resources and
features of every user from every server on the planet is completely
insane. Don't be surprised if you see memory leaks - they are by design :)
Not
-Original Message-
From: jdev-boun...@jabber.org [mailto:jdev-boun...@jabber.org] On Behalf Of
Mathias Ertl
Sent: Friday, August 27, 2010 11:49 AM
To: jdev@jabber.org
Subject: Re: [jdev] The future of Jabber/XMPP?
To be fair, Stephen Pendleton claimed earlier in this thread
-Original Message-
From: jdev-boun...@jabber.org [mailto:jdev-boun...@jabber.org] On Behalf Of
Tomasz Sterna
Sent: Friday, September 03, 2010 9:04 AM
To: Jabber/XMPP software development list
Subject: Re: [jdev] The future of Jabber/XMPP?
One may wonder whether low penetration of PEP
-Original Message-
From: jdev-boun...@jabber.org [mailto:jdev-boun...@jabber.org] On Behalf Of
Tuomas Koski
Sent: Tuesday, September 21, 2010 7:16 AM
To: Jabber/XMPP software development list
Subject: [jdev] Best ways for a JID to advertise what services it uses?
...
what are the best
-Original Message-
From: jdev-boun...@jabber.org [mailto:jdev-boun...@jabber.org] On Behalf Of
René Treffer
Sent: Friday, October 29, 2010 8:56 PM
To: jdev@jabber.org
Subject: [jdev] XMPP on Android, Round #2
Hi,
It's been some time since my last posting. But I didn't stop thinking
-Original Message-
From: jdev-boun...@jabber.org [mailto:jdev-boun...@jabber.org] On Behalf Of
Peter Saint-Andre
Sent: Thursday, October 28, 2010 1:41 PM
To: Jabber/XMPP software development list
Subject: Re: [jdev] Possible Off Topic but of XMPP Interest: Wiki Leaks uses
XMPP
On
-Original Message-
From: jdev-boun...@jabber.org [mailto:jdev-boun...@jabber.org] On Behalf Of
Yann Leboulanger
Sent: Monday, November 01, 2010 4:27 PM
To: jdev@jabber.org
Subject: Re: [jdev] XMPP on Android, Round #2
Couldn't Stream managment help for that?
-Original Message-
From: jdev-boun...@jabber.org [mailto:jdev-boun...@jabber.org] On Behalf Of
Rene Treffer
Sent: Tuesday, November 02, 2010 4:09 PM
To: jdev@jabber.org
Subject: Re: [jdev] XMPP on Android, Round #2
On 11/01/2010 10:14 PM, Stephen Pendleton wrote:
-Original Message
-Original Message-
From: jdev-boun...@jabber.org [mailto:jdev-boun...@jabber.org] On Behalf Of
Rene Treffer
Sent: Tuesday, November 02, 2010 6:33 PM
To: Jabber/XMPP software development list
Subject: Re: [jdev] XMPP on Android, Round #2
On 11/02/2010 10:24 PM, Stephen Pendleton wrote
-Original Message-
From: jdev-boun...@jabber.org [mailto:jdev-boun...@jabber.org] On Behalf Of
Stephen Pendleton
Sent: Tuesday, November 02, 2010 8:07 PM
To: 'Jabber/XMPP software development list'
Subject: Re: [jdev] XMPP on Android, Round #2
By the way if you guys are interested
-Original Message-
From: jdev-boun...@jabber.org [mailto:jdev-boun...@jabber.org] On Behalf Of
Rene Treffer
Sent: Wednesday, November 03, 2010 5:16 AM
To: Jabber/XMPP software development list
Subject: Re: [jdev] XMPP on Android, Round #2
-Original Message-
From:
-Original Message-
From: jdev-boun...@jabber.org [mailto:jdev-boun...@jabber.org] On Behalf Of
Rene Treffer
Sent: Friday, November 05, 2010 11:58 AM
To: Jabber/XMPP software development list
Subject: Re: [jdev] XMPP on Android, Round #2
a) you don't need a wake look to keep the
-Original Message-
Hi..
In our first approach I'm counting on ARM9 based embedded system with
linux running on top of it and probably Java as programming
environment (there will be also implemented ReST access to the
network). I designed HW platform which is agnostic to the
Buddycloud is far superior to anything you are going to find or build
yourself in and out of the XMPP world. Period. Also, Buddycloud is superior
to the walled garden stuff like Yammer.
I don't contribute to Buddycloud development, but I know those guys work
hard on it, so for you to infer it has
78 matches
Mail list logo
