Hi.
Please ignore this message. I hadn't read the latest version of the
XEP, and the "MAY be a unique identifer that is opaque to the client
but understood by the server" covers most if not all of my argument
below. :)
Best regards,
On Mar 6, 2008, at 10:23 PM, Pedro Melo wrote:
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 meaning is.
I agree that servers will use a counter or sequence per roster for
this, because its efficient and they can easily see what needs to
be sent to the client. What I don't get is why we should force that
in the spec, given that the client never uses the version
semantically, he only sends it back to the server.
I think the version should be specifiec as a opaque string, and in
the implementation notes recommend strongly the use of a counter
for the reasons Dave Cridland gave.
I'll let Dave Cridland explain why he thinks this is not
overspecification. I think his experience with IETF email and data
storage protocols is relevant here. In particular, during the Council
meeting [1] he said:
"It's a lot more efficient with an int, and everything else is either
worse performance, fails entirely, or else is equivalent
difficulty to
an int."
he is right but thats a server issue, Clients don't care, they
store it and send it back later.
So at most this is relevant as implementation notes for servers.
Again: I think most of us agree that servers will use an integer
counter because its the most efficient way to implement the entire
XEP.
What I don't see is the need to tell that in the spec, therefore
limiting us for the future.
"One interesting point is that with an int, there's always
something a
client can use to get the entire roster, with versioning turned on."
Sending a 0? what about sending an empty version attribute? Same
thing.
"I'm not quite sure what the client ought to send if everything's
completely opaque - it'd need more syntax."
Empty?
"Put it this way, since the counter-proposal involved timestamps,
which
are known to be broken, I'm pretty sure people will get stuff wrong
without it being a MUST."
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.
Server authors have to get it right based on their architecture of
their server, and that is something that I don't think specs should
meddle with.
And previously on the list he said [2]:
"strictly increasing numeric sequences have proved useful in the IMAP
world, because clients can spot when things go wrong much more
easily."
Agreed. Hence a recommendation on implementation notes to use a
counter with those properties.
Best regtards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: [EMAIL PROTECTED]
Use XMPP!
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: [EMAIL PROTECTED]
Use XMPP!
