>- 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 <[email protected]>: > 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 [email protected] http://tbspace.de
