http://code.google.com/android/migrating/m3-to-m5/m5-api-changes.html#gtalk
I think this just stands to open the whole binary encoded debate once
again. I'm too much of a coward to be caught in the crossfire so I
will duck out and not give my opinion.
Google's group manager of wireless will be keynoting and then on a
panel the next day promoting Android vs other mobile
On Thu, 2008-02-14 at 09:55 +0100, biojab biojab wrote:
http://code.google.com/android/migrating/m3-to-m5/m5-api-changes.html#gtalk
Well, there really is a very valid point in not wanting to implement
standard XMPP for mobile devices. While XML-based communication is easy
to work with, it is
What would be the preferred way of getting the list of MUCs in a server
and the number of occupants in each MUC (using XMPP client)? I guess
XEP-0045 doesn't directly support this functionality? I only found in
the specification that you can get a list of all MUCs using XEP-0045 and
then for each
extended disco info has muc#roominfo_occupants (Number of occupants)
On Thu, Feb 14, 2008 at 12:53 PM, Juha Mynttinen
[EMAIL PROTECTED] wrote:
What would be the preferred way of getting the list of MUCs in a server
and the number of occupants in each MUC (using XMPP client)? I guess
XEP-0045
On Thu, Feb 14, 2008 at 10:12 AM, Lee Dryburgh [EMAIL PROTECTED] wrote:
I think this just stands to open the whole binary encoded debate once
again. I'm too much of a coward to be caught in the crossfire so I
will duck out and not give my opinion.
Once I was one of those baldly standing for
Alex Malinovich schrieb:
... it is really terribly inefficient. What we really need to
do is establish a STANDARD binary protocol for transmitting XMPP
information. Essentially a binary-encoding standard for XMPP. Then as
long as servers support that extension, clients will remain unaffected.
That is:
http://www.xmpp.org/extensions/xep-0045.html#example-8
On Thu, Feb 14, 2008 at 01:03:18PM +0200, Norman Rasmussen wrote:
extended disco info has muc#roominfo_occupants (Number of occupants)
On Thu, Feb 14, 2008 at 12:53 PM, Juha Mynttinen
[EMAIL PROTECTED] wrote:
What would be
biojab biojab wrote:
http://code.google.com/android/migrating/m3-to-m5/m5-api-changes.html#gtalk
First of all, don't panic.
As I understand it from one of the Android team members, they have been
using XMPP communications (sent only via the Google Talk service) as a
way for developers to debug
I don't think Cialis Soft is supported by XMPP any more.
On Thu, Feb 14, 2008 at 3:00 PM, jdev@jabber.org wrote:
--
Courage in an untrained mind leads to cruelty, and in a trained mind
it leads to hope and compassion. ~ P.J. Saher
Maybe we could paint the XML Binary proposal in blue.
Then we could joke about the 79% OFF subject in a on-topic way.
Best regards,
On Feb 14, 2008, at 9:37 PM, Sean Gilbertson wrote:
I don't think Cialis Soft is supported by XMPP any more.
On Thu, Feb 14, 2008 at 3:00 PM, jdev@jabber.org
It appears that few (none?) of the out of box J2ME bits on mobile
devices support switching of an previously established un-encrypted
session to TLS via the STARTTLS sequence ( i.e Connections that start
un-encrypted, then send STARTTLS to become encrypted )
Any one have pointers to a library
On Fri, Feb 15, 2008 at 12:10 AM, Ernest Nova
[EMAIL PROTECTED] wrote:
It appears that few (none?) of the out of box J2ME bits on mobile
devices support switching of an previously established un-encrypted
session to TLS via the STARTTLS sequence ( i.e Connections that start
un-encrypted,
More questions have popped up from reading the privacy extension doc at
http://www.xmpp.org/extensions/xep-0016.html.
When a client updates a privacy list, it must include all of the desired
items (i.e., not a delta).
My reading of this is when I want to allow or deny a single person I have
14 matches
Mail list logo
