On Mon Mar 17 16:31:06 2008, Peter Saint-Andre wrote:
Dave Cridland wrote:
> On Mon Mar 17 15:22:28 2008, Peter Saint-Andre wrote:
>> Pedro Melo wrote:
>> > Lets not abuse the meaning of <message> just because we like
their
>> > network properties, like we abused <presence> in the past
because it
>> > broadcasts well.
>>
>> +1.
>>
>>
> Absolutely. So I'm looking forward to seeing the update to
XEP-0060
> which changes PubSub pushes from being <message/> to <iq/>, in
(for
> example) section 7.1.2.1.
>
> Or, alternately, could someone explain to me why the use of
<message/>
> stanzas for the 7.1.2.1 case is not "abuse", whereas would be.
Looks to
> me like they're the same use-case.
Very funny. :P
We use messages there in part because using IQs would require
knowing
the full JID (and stock pubsub services do not know that).
Gosh - you mean you chose <message/> because of its network
properties? ;-)
But that's neither here nor there. The question is whether:
(1) acking an occasional roster push from the server to the client
(where BTW the server *does* know your full JID) is a serious
problem
that we need to solve because it wastes large amounts of bandwidth
It's not the bandwidth, it's the additional transmission I'm more
concerned with. For every <iq/> stanza, there's an addition TCP data
packet, and therefore there'll be a further ACK - both of which will
cost power.
The alternative is that we quietly explain to people that they
needn't bother replying to the <iq/> push, which I really don't like.
I'm pretty sure that the mobile developers won't want to reply to
every roster push, anyway.
or
(2) sending roster pushes via <message/> is a pretty optimization
that
is more elegant than what we developed in 1999, but it fundamentally
unnecessary
I think (2) obtains. Therefore I think it's just fine to keep IQs
for
roster pushes. If it ain't broke, don't fix it.
Nothing here is necessary; the question is whether we can, and
should, do it.
Remember, rosters are not broken right now - they work just fine. So,
if we're going to change things, we may as well consider how much we
can change things, rather than how little.
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
