[Operators] Future of XMPP Re: The Google issue
holler at ahsoftware.de
Wed Dec 4 00:02:26 UTC 2013
Am 03.12.2013 23:55, schrieb Solomon Peachy:
> On Tue, Dec 03, 2013 at 11:03:27PM +0100, Alexander Holler wrote:
>> So you think it is an elegant way that if a machine wants to send 10
>> binary bytes to another machine, it is ok to put them into mime64,
>> pack that into XML, authorize and authenticate with an XMPP-server.
>> doing the necessary presence stuff to finally send out a message or
> It sounds like your objection is to the use of XMPP more so than its use
> of XML. If you don't want (or need) XMPP's feature set
> (discoverability, authentication, presence, security, etc) then why
> would you use it to begin with? If you do need that feature set, then
> you're going to have to deal with the complexity those features
> necessarily entail.
In fact I like XMPP, mostly because it's an open standard and it got
many concepts right and worked out (specified) well. What I don't like
about XMPP is the XML part and the need for TCP but one can't have
> Meanwhile, back on the XML front -- if those "ten binary bytes" need to
> go aross the public internet to unknown/unstable IP addresses and be
> secure from snooping or spoofing, then the added complexity of XML
> encoding is pretty minor once you have all the other parts in place.
> Nevermind what happens when it's time to introduce a new message type
> or another argument to an existing type. Are you absolutely sure you
> didn't break your parser in the process? Does the old parser
> handle the new messages without errors?
But that discussion doesn't lead to anything solvable. The problem here
already starts with what M2M should stand for.
If you go embedded and/or industrial you even have a problems to "sell"
something Linux based. It's a very conservative environment were people
often even don't know anything about TCP/IP, machines have to work in
hazardous environments and stuff often has to live and work for
centuries. Something completely different to environments usually served
by network centric companies.
And now try to explain them how to integrate an XMPP-client and maybe
server into their things and try to explain those people why an
XML-parser should be necessary to send some bytes.
> XMPP, like any engineering effort, required tradeoffs between
> conflicting prinicples. The gains from using XML as a transport layer
> vastly exceeded the downsides. Over time, that tradeoff has only become
> more pronounced.
I disagree and do think there are better ways than using XML. But I
don't care much about that XML in the usual environment, I just don't
think that XMPP, in it's current state, is the ideal solution for M2M
(whatever M2M might be). For me, M2M sounds like
- machines should be able to communicate without the need for a server
- small hardwares (like AVR based Arduinos) should be able too to do M2M
too without the need for some daughter board with a much bigger CPU and
megabytes of RAM,
(- redundant machines aren't the norm,)
(- load-balancing doesn't exist)
And I don't see how that will happen.
I don't have a problem to build an ARM based XMPP-server with just 16MB
RAM (ok, it will have "some" limits, but it works ;) ), but even such
simple looking things might have the need to be reviewed by someone
else. And now find someone who reviews a XML-parser (no I didn't have
written one by myself, my time is limited and nobody pays me to do so ;)
) and later on all the XMPP-specific stuff.
But I don't know with what happens on the M2M front. I just don't think
that XMPP is the ideal candidate for that and maybe XMPP 3.x should be
defined (without XML and TCP). E.g. the presence concepts of XMPP are
pretty good and I don't think that can be done much better, but I would
like if presence would be optional for M2M. The same for authentication
and authorization as many machines communicate using their own networks
and don't need authentication and or authorization (or even SSL).
I still think XMPP is still pretty nice, but I have my concerns in
regard to using XMPP for M2M.
More information about the Operators