Hi Scott, Heh, I guess I need to read more closely. I see now that Tad was the one who talked about base64. Sorry!
On Sep 7, 2:20 pm, "[email protected]" <[email protected]> wrote: > Hi Scott, > > It sounds like one thing you are suggesting is binary transport? > > Specifically, you wrote: > > On Sep 6, 11:10 pm, Tad Glines <[email protected]> wrote: > > Plus the 25% increase in size due to the Base64 encoding. Okay, now that I've got that sorted out... I see a few advantages to using an XMPP server for federation: 1. Reuse of XMPP code. You point out that there are downsides to this, such as the extra network communication and XML coding/decoding involved, but these could be addressed with improvements to the XMPP server or protocol. By reusing the XMPP code, both the wave developers and the XMPP developers benefit from the cooperation. 2. Reuse of the XMPP port for wave communications - admittedly, if you didn't want to run an XMPP server, you wouldn't care about reusing the port, but from the perspective of IANA or system administrators, the hard work has already been done to establish a standard for XMPP server connections (look up the SRV record, default to port 5222, etc.). The code has already been written in many places. 3. The wave server hopefully does most of its communication using client-server connections, not federated connections. 4. The wave server itself does not listen on a public-facing port (less risk of an exploit). On the other hand, I still feel there are a few things in the wave protocol that might be improved: 1. Use of JIDs. On Sep 7, 6:08 am, Sam Thorogood <[email protected]> wrote: > For instance, we don't even use traditional JIDs: messages aren't > delivered to [email protected], they're delivered to > wave.wavesandbox.com which interprets the messages (as deltas etc) and > maps the resulting wavelets to the server's users. I'd probably use a JID like wavesandbox.com/waveresource. I am aware of http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-01#section-4.2, which says: "Note: Many XMPP servers are implemented in such a way that they can host additional services (beyond those defined in this specification and [xmpp-im]) at hostnames that are subdomains of the hostname of the main XMPP service (e.g., conference.example.net for a [XEP-0045] service associated with the example.net XMPP service) or subdomains of the first-level domain of the underlying host (e.g., muc.example.com for a [XEP-0045] service associated with the im.example.com XMPP service)." Some servers will want the scalability of a multi-domain-name setup. I feel first-time users will find it less confusing if they don't need to set up more DNS entries though. OpenFire would be one of the XMPP servers "implemented in such a way that they can host additional services at hostnames that are subdomains" ... that can be worked around. 2. Use of pubsub In short: wave uses pubsub for history requests (and some other things) and messages for deltas, but I can't see any gain from "reusing" pubsub for this. Pubsub allows the XMPP server to broadcast messages to multiple clients when one client publishes an update. However, wave uses XEP-0114, and the XMPP server just passes its pubsub packets through like any other packet. This is the right way to do things: you wouldn't have two wave servers connected to the same XMPP server and subscribing to each others' pubsubs. However, it does lead to the question: if pubsub is not doing any broadcasting, why apply it to the wave federation protocol? David --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en -~----------~----~----~----~------~----~------~--~---
