On 1/5/2012 8:08 AM, Matthew Miller wrote:
On Jan 5, 2012, at 09:03, Mike Wacker wrote:
On 1/5/2012 7:43 AM, Matthew Miller wrote:
On Jan 5, 2012, at 08:41, Mike Wacker wrote:
On 1/5/2012 7:31 AM, Matthew Miller wrote:
On Jan 5, 2012, at 08:24, Mike Wacker wrote:
Let me suggest a bolder idea. Why do we need to wrap the carbons using Message
Forwarding at all instead of just delivering the message stanzas as is? You
will only receive these additional message carbons if your client supports
carbons and enables carbons. Thus, if a client has carbons enabled, if it
receives a message not sent to its bare JID or full JID (either a message from
one of its other resources to a buddy or from a buddy to one of its other
resources), it can reasonably infer that the message is a carbon.
The standard use cases for message carbons is to ensure that a given device
will receive both sides of all conversations, and that use case is covered
regardless of whether we wrap carbons or not. I can't think of any use case for
the special wrapping logic, though.
This would greatly simplify the XEP (as well as eliminate a dependency on an
experimental XEP more complex than message carbons itself), as servers would
only have to route the messages and not modify them, and clients won't need
special parsing logic for carbons.
The original version of XEP-0280 did just that. However, while it appears to
simplify the XEP, it complicated implementations. It required routing
a<message/> to a client that did not match the 'to', which raised a number
of concerns among client and server implementers.
And I disagree that XEP-0297 is more complex than carbons.
- m&m
<http://goo.gl/LK55L>
Could you elaborate on those concerns? A client would only receive a message
that did not match the 'to' if it had message carbons enabled. Thus, it would
be reasonable that these clients would have special logic to handle such
messages if it supported carbons and if it had them enabled. Clients not
supporting message carbons do not need to make any changes.
The problem is not just with the clients; it's also with servers. The server
must route that message, and not every server implementation is readily
prepared to deal with that radical of a departure for standard XMPP routing
rules.
- m&m
<http://goo.gl/LK55L>
Perhaps an actual case could help elaborate, in theory, all you need to do is
alter the routing logic and perhaps also alter some checks/assertions for
messages which don't match the 'to' field. Neither seems prohibitively
expensive. It doesn't seem that complex on the client either.
I'm just looking for a better rationale for it. If there's a client use case or
user experience which requires the wrapping, then we definitely need it. If
it's a task that can be offloaded from the server to the client, that is also a
valid reason. But I'm not a huge fan of altering the message just to simplify
server implementation details for a task that belongs to the server [routing].
Unless there's a really compelling cost or scalability reason, I prefer that we
build the protocol around client use cases and user experiences instead of
building it around the server implementation.
I appreciate your feedback, but completely disagree with your assessment. I
know there are others that disagree, because I made the change based on their
feedback on this list.
- m&m
<http://goo.gl/LK55L>
Matthew,
I understand that you disagree, but I want to get a better understanding
of your disagreement, in particular the server concerns. (Would I be
right in assuming this decision is more server-driven than client-driven?)
First, I hope that we can agree that in the "ideal" world (though I
acknowledge no world is ideal and that things like scalability don't
grow on trees), the protocol should be designed around user experiences
and client use cases, not server implementation details.
But it seems like we have two types of server implementations: those
which can easily handle the change and those which cannot. For clients
or servers which can easily handle the change, this message wrapping
logic serves no useful purpose and is extra overhead. For servers which
cannot easily handle the change, this change will have a significant
effect in terms of reducing the implementation cost, but at a (smaller)
cost expense to client and servers which can easily handle the change.
Mike
