On Fri Jan 25 17:07:48 2008, Martin Sustrik wrote:
Richard,
Base64 is trivial to compute and as far as TLS is concerned surely
being financial information you would be required to have it
encrypted? The encryption rather than the compression part is
likely to be the most CPU intensive part.
Not really. The high-volume distribution scenarios tend to appear
in closed environments where encryption is not required. I don't
expect XMPP to be really well-performing here, but there's no much
point of using XMPP is such an environment anyway.
I'd agree with that. Slipping on a work hat for a moment, we - Isode
- use a mostly binary messag passing protocol for internal messaging
inside our applications, although the payloads often turn out to be
XML. We have considered using XMPP directly, but dropped it for the
same efficiency reasons you've cited, but equally, we are planning on
using XMPP for various out-bound interoperability and integration
issues.
On the other hand, in low-volume over-the-internet messaging, XMPP
may be interesting. Actually, I am starting to like the idea of the
plug-in - not least because there is an active community around
XMPP that may help with implementing particular features. The other
way round, this may be an interesting toehold in financials for
XMPP community.
Absolutely - also there's considerable usage of XMPP within the
financials anyway, so enabling various tie-in technologies makes
sense. The latency increases of running over XMPP, for example, would
be far outweighed by having a stock-ticker in Psi, say.
You also need to define "low-volume" for this community - I suspect
your "low-volume" equates to, or exceeds, our "flood". :-)
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
