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.
