[Operators] Future of XMPP Re: The Google issue

Tobias Mädel t.maedel at alfeld.de
Wed Dec 4 08:30:17 UTC 2013


>- 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,

as I already mentioned, it is possible to do XML-based XMPP on an Arduino.
http://old.ethersex.de/index.php/Feature_Liste

Regards,
Tobias

2013/12/4 Alexander Holler <holler at ahsoftware.de>:
> 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
>>> iq-stanza?
>>
>>
>> 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 everything.
>
>> 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.
>
> Regards,
>
> Alexander Holler



-- 
#define true ((rand() % 2)? true: false)
Tobias Mädel
t.maedel at alfeld.de
http://tbspace.de


More information about the Operators mailing list