Hi,
On Mar 5, 2009, at 4:41 PM, Mickael Remond wrote:
Pedro Melo wrote:
In my view, "opaque" is applied to the client point of view. I have
no
problems that a field, generated by the server, and only used by the
same server (server here could mean a set of servers working
together)
has some meaning to it.
I would imagine for example, that I could have a sm-id as ID,HMAC
where I can check if the ID was not tampered with. The sm-id is
opaque
to the client and has meaning to the server.
Yes, but the problem is that this decision adds yet another routing
criteria on the server (looking up where is the session you want to
resume is a routing algorithm).
Most of the routing on the server is done through JID and you have all
the infrastructure in place on the server to cope with that.
That's not really true for all server. I know at least one server that
uses the session for internal routing.
But I wasn't complaining about the inclusion of the full JID. If you
think that it will make the job of some servers easier (and reading
down the thread, it really seems to make a difference, I like you view
"jid = ID, sm-id = access key", I say include it. My point was just
saying that opaque is only applied to the client.
So, you have to build another routing table at the implementation
level.
I have been given many reason why the sm-id was something sufficent
enough, but no reason explaining why requiring the full JID to
resume a
session was a bad design decision.
As I said above, I was only pointing out that opaque applies to the
client :).
I feel a bit alone to defend this view, and I am suddently afraid to
have been struck by early Elzeimer disease :)
Well, I don't know about that, you should check your doctor. But you
are not alone. :)
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: m...@simplicidade.org
Use XMPP!
