I couldn't resist.
On May 7, 2013, at 11:47 AM, Peter Saint-Andre stpe...@stpeter.im wrote:
On 5/7/13 12:38 PM, Simon Tennant wrote:
My next grumpy-old-man comment is the residual use of Jabber in the
specs. I'd love to submit a pull request in to fix this (via Github).
Most of the main
between 1 and 3071 (see 3920bis)
+1
__
Robert Quattlebaum
Jabber: da...@deepdarc.com
eMail: da...@deepdarc.com
www:http://www.deepdarc.com/
. While I need to give this approach
some more thought, this XEP seems like a reasonable start.
__
Robert Quattlebaum
Jabber: da...@deepdarc.com
eMail: da...@deepdarc.com
www:http://www.deepdarc.com/
On Dec 15, 2008, at 7:03 PM, Justin Karneges wrote:
On Monday 15 December 2008 15:08:00 Robert Quattlebaum wrote:
Presence probes are useful to force a refresh of your presence state
if you were previously ignoring presence (say, via a privacy list
which blocks incoming presence).
It should
to determine when it is moving from a list which doesn't allow
incoming presence to a list which does. Not hugely complex, but not
trivial...
Although perhaps a trivial implementation of *always* doing a probe
when the privacy list changes isn't a horrible idea.
__
Robert
to each individual on their contact list.
Additionally, a service discovery feature may need to be created to
allow servers to advertise that they support this behavior correctly.
Thoughts?
__
Robert Quattlebaum
Jabber: da...@deepdarc.com
eMail: da...@deepdarc.com
www:http
this also drop the message on the floor? I'm pretty sure
it won't get added to the offline message queue.
__
Robert Quattlebaum
Jabber: da...@deepdarc.com
eMail: da...@deepdarc.com
www:http://www.deepdarc.com/
Oops... I should read the thread more carefully before posting. My
question was already addressed.
Sorry.
On Dec 15, 2008, at 4:29 PM, Robert Quattlebaum wrote:
On Dec 2, 2008, at 1:02 PM, Jack Erwin wrote:
Dirk Meyer wrote:
First of all, we need some sort of negative priority for bots
.
***
__
Robert Quattlebaum
Jabber: [EMAIL PROTECTED]
eMail: [EMAIL PROTECTED]
www:http://www.deepdarc.com/
I was actually confused into thinking that XML 1.1 was just
XML1.0+Namespaces... Which happens to not be the case.
So replace XML 1.1 with XML 1.0+Namespaces, and my original
comment will make sense. :)
On Oct 14, 2008, at 3:49 PM, Peter Saint-Andre wrote:
Robert Quattlebaum wrote:
I
On Feb 1, 2008, at 1:14 AM, Maciek Niedzielski wrote:
Robert Quattlebaum pisze:
On Jan 31, 2008, at 1:10 AM, Michal 'vorner' Vaner wrote:
Why couldn't it know now? If you are unable to filter/register by
other
criteries than just the namespace of toplevel child, then you will
find
On Jan 31, 2008, at 9:58 AM, Peter Saint-Andre wrote:
Robert Quattlebaum wrote:
On Jan 30, 2008, at 9:14 PM, Peter Saint-Andre wrote:
Why is it not possible for a plugin to register for Jingle-related
events based on the application type? Once a plugin receives such an
event, it can
to an incoming IQ. The only case where it
would be reasonable to send an incoming IQ to multiple plug-ins is if
all but one of the plug-ins are only observing and will never reply.
__
Robert Quattlebaum
Jabber: [EMAIL PROTECTED]
eMail: [EMAIL PROTECTED]
www:http
On Jan 31, 2008, at 2:20 AM, Lauri Kaila wrote:
2008/1/31, Michal 'vorner' Vaner [EMAIL PROTECTED]:
Hello
On Wed, Jan 30, 2008 at 05:53:21PM -0800, Robert Quattlebaum wrote:
But the truth is that all of that complexity isn't even necessary,
as long
as the XMPP client daemon can know where
they leak the MAC address of the primary network
card. If you are going to explicitly encourage the use of UUID's, I
think you should explicitly recommend against using UUID generation
methods which would leak such information.
__
Robert Quattlebaum
Jabber: [EMAIL PROTECTED
On Jan 30, 2008, at 6:08 PM, Greg Hudson wrote:
On Wed, 2008-01-30 at 17:53 -0800, Robert Quattlebaum wrote:
What if these plug-ins are actually separate processes? Imagine if
you
were using some sort of XMPP client daemon, for example. In such a
setup, you would have separate processes
16 matches
Mail list logo
