Dave Cridland [EMAIL PROTECTED] writes:
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
On Tue Mar 18 02:51:53 2008, Peter Saint-Andre wrote:
Dave Cridland wrote:
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
Pedro Melo wrote:
Hi,
On Mar 11, 2008, at 12:06 AM, Dave Cridland wrote:
On Mon Mar 10 23:45:28 2008, Peter Saint-Andre wrote:
One potential problem: this is not a nice, small, incremental change.
Now servers and clients must support:
1. The 'sequence' attribute.
2. Roster pushes via
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
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).
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
Richard Dobson wrote:
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).
But that's neither here nor there. The question is whether:
(1) acking an occasional roster push from the server to the
Hi,
On Mar 17, 2008, at 3:22 PM, Peter Saint-Andre wrote:
Pedro Melo wrote:
On Mar 11, 2008, at 12:06 AM, Dave Cridland wrote:
On Mon Mar 10 23:45:28 2008, Peter Saint-Andre wrote:
One potential problem: this is not a nice, small, incremental
change.
Now servers and clients must support:
Hi,
On Mar 17, 2008, at 10:11 PM, Peter Saint-Andre wrote:
Pedro Melo wrote:
On Mar 17, 2008, at 3:22 PM, Peter Saint-Andre wrote:
Pedro Melo wrote:
On Mar 11, 2008, at 12:06 AM, Dave Cridland wrote:
On Mon Mar 10 23:45:28 2008, Peter Saint-Andre wrote:
One potential problem: this is not a
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
Pedro Melo wrote:
Hi,
On Mar 17, 2008, at 10:11 PM, Peter Saint-Andre wrote:
Pedro Melo wrote:
On Mar 17, 2008, at 3:22 PM, Peter Saint-Andre wrote:
Pedro Melo wrote:
On Mar 11, 2008, at 12:06 AM, Dave Cridland wrote:
On Mon Mar 10 23:45:28 2008, Peter Saint-Andre wrote:
One potential
Dave Cridland wrote:
On Mon Mar 17 16:31:06 2008, Peter Saint-Andre wrote:
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
On Mon Mar 10 20:17:53 2008, Joe Hildebrand wrote:
In section 2.4, would it be easier to implement in existing clients
if:
- The response to the iq/get with version 0 was a full roster, in
the existing format, with the addition of the current version
number
I think it is, isn't it? The
On Mar 10, 2008, at 2:32 PM, Dave Cridland wrote:
On Mon Mar 10 20:17:53 2008, Joe Hildebrand wrote:
In section 2.4, would it be easier to implement in existing clients
if:
- The response to the iq/get with version 0 was a full roster, in
the existing format, with the addition of the
Peter Saint-Andre wrote:
Dave Cridland wrote:
On Mon Mar 10 20:17:53 2008, Joe Hildebrand wrote:
In section 2.4, would it be easier to implement in existing clients if:
snip/
- All changes would be sent to the client as roster pushes after the
iq/response, ordered such that the last one
On Mon Mar 10 23:45:28 2008, Peter Saint-Andre wrote:
One potential problem: this is not a nice, small, incremental
change.
Now servers and clients must support:
1. The 'sequence' attribute.
2. Roster pushes via message, not IQ.
3. Multiple items in a roster push.
4. Multiple items in a
Hi!
Comments below marked as jph:
Cheer's
Juha
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of ext Peter Saint-Andre
Sent: 06 March, 2008 06:36
To: XMPP Extension Discussion List
Subject: Re: [Standards] Proposed XMPP Extension: Roster Versioning
On Thu Mar 6 07:50:32 2008, Justin Karneges wrote:
What counts as what is a matter of what the usual design practices
and trends are for related specifications. My assessment, from
what I read in the mailing list arguments, is that opaque was in
the 'neutral' category. Thus it should not
Dave Cridland wrote:
Then it doesn't get versioning. (BTW, I hate that name - there are no
versions kept. It's not like a client can ask for a previous version,
and nor does a server need to keep any previous versions).
I'm not wedded to that name. Feel free to suggest another. Roster diffs?
Dave Cridland wrote:
On Thu Mar 6 17:25:18 2008, Peter Saint-Andre wrote:
Dave Cridland wrote:
Then it doesn't get versioning. (BTW, I hate that name - there are no
versions kept. It's not like a client can ask for a previous version,
and nor does a server need to keep any previous
On 6-Mar-08, at 12:50 AM, Justin Karneges wrote:
What counts as what is a matter of what the usual design practices
and trends
are for related specifications.
An other factor to consider is how most people actually implement a
protocol. Guess what, it's not by reading the RFCs and XEPs
Curtis King wrote:
On 6-Mar-08, at 12:50 AM, Justin Karneges wrote:
What counts as what is a matter of what the usual design practices and
trends
are for related specifications.
An other factor to consider is how most people actually implement a
protocol. Guess what, it's not by
Hi,
On Mar 6, 2008, at 4:27 AM, Peter Saint-Andre wrote:
I'm not convinced that that's the intent. It seems that it might be
useful in some situations for the client to know where it stands.
If we are going to have semantic meaning the in the version then the
spec must reflect what the
On Thu Mar 6 22:23:51 2008, Pedro Melo wrote:
Others might counter-propose something meaningful but some are
proposing something opaque, without meaning for the client. And
that is the best way for clients not to mess up.
Okay, I call. :-)
How *can* clients mess this up by knowing they
On Wed Mar 5 11:00:34 2008, Richard Dobson wrote:
Sometimes flexibility comes back to bite you. I'd prefer to keep
things
simple if we can. What does the extra flexibility really do for
us, and
is it worth the cost?
Well I think it is better to be flexible in this case otherwise its
You can't use timestamps - they're not strictly increasing, for
various reasons.
Why does it need to be strictly increasing? As already explained the
version identifiers should IMO be opaque and just be a server
implementation issue, I still can't see any reason why this needs to be
set in
Richard Dobson wrote:
You just use a 128-bit unsigned integer. There is no upper limit here
- in particular, there is no upper limit specified anywhere in this
document - XSD merely states that a xs:nonNegativeInteger is a
sequence of digits, and has countably infinite cardinality.
If you
Peter Saint-Andre wrote:
If we change it to a SHOULD will that make people happier? We do
something similar in server dialback (recommend an algorithm for key
generation using HMAC-SHA256, but say you can use something else).
Here is revised text:
The value of the 'version' attribute
Peter Saint-Andre schrieb:
Here is revised text:
The value of the 'version' attribute SHOULD be a non-negative
integer representing a strictly increasing sequence number that
is increased with any change to the roster (whether or not the
client supports this extension) but MAY be a
backwads 1...n?
Cheer's
Juha
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of ext Alexander Gnauck
Sent: 05 March, 2008 22:45
To: standards@xmpp.org
Subject: Re: [Standards] Proposed XMPP Extension: Roster Versioning
Peter Saint-Andre schrieb:
Here
Alexander Gnauck wrote:
Peter Saint-Andre schrieb:
Here is revised text:
The value of the 'version' attribute SHOULD be a non-negative
integer representing a strictly increasing sequence number that
is increased with any change to the roster (whether or not the
client supports
Peter Saint-Andre wrote:
Alexander Gnauck wrote:
Peter Saint-Andre schrieb:
Here is revised text:
The value of the 'version' attribute SHOULD be a non-negative
integer representing a strictly increasing sequence number that
is increased with any change to the roster (whether or not
On Wednesday 05 March 2008 5:33 pm, Richard Dobson wrote:
Peter Saint-Andre wrote:
Alexander Gnauck wrote:
Peter Saint-Andre schrieb:
Here is revised text:
The value of the 'version' attribute SHOULD be a non-negative
integer representing a strictly increasing sequence number
On Tue Mar 4 21:54:31 2008, XMPP Extensions Editor wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Roster Versioning
Abstract: This specification proposes a modification to the XMPP
roster management protocol to support versioning of rosters for
more
Hi,
On Mar 4, 2008, at 10:27 PM, Dave Cridland wrote:
On Tue Mar 4 21:54:31 2008, XMPP Extensions Editor wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Roster Versioning
Abstract: This specification proposes a modification to the XMPP
roster management
Dave Cridland wrote:
On Tue Mar 4 21:54:31 2008, XMPP Extensions Editor wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Roster Versioning
Abstract: This specification proposes a modification to the XMPP
roster management protocol to support versioning of
Richard Dobson wrote:
+1. I can't see any reason for the spec to require more than a
increasing version number.
I would prefer if it were just an opaque string, certainly as far as the
client in concerned there is no need for it to do anything other than
store the most recent version
Peter Saint-Andre wrote:
URL: http://www.xmpp.org/extensions/inbox/roster-versioning.html
BTW version 0.0.2 is available. Reload as needed.
/psa
smime.p7s
Description: S/MIME Cryptographic Signature
37 matches
Mail list logo
