A Tardy, but Hardy Welcome

[arlen....@eurotech.com]

Hello and Happy 2012 to everyone in the MQTT Discussion Group!

I hope that everyone can tell that a lot of us have been quite busy
over the last 6 months working with the IBM team, the Eclipse M2M
Industry Working Group, many editors/analyst and select technical
forums to help promote both the visibility and the use of MQTT.

As one of the original developers of the specification along with Andy
Stanford Clark, and having used MQTT in anger for the last 12 years I
probably have a biased view of MQTT. I do consider myself an
"opportunistic" technologist and with that being said, I still have
not seen anything close to MQTT in the target market that it was
designed for.

Is MQTT the right messaging transport choice for "Everything"
embedded? Definitely not! But is it fit for purpose in solving a lot
of everyday embedded computing messaging problems? Most Definitely.
With the current emergence of these notions around M2M and IoT
(Internet of Things) along with the availability of inexpensive Cloud
platforms, I believe MQTT is very well positioned to provide this
ecosystem with a very viable/reliable messaging technology.

MQTT was originally invented to bridge that murky and ill defined area
between the deeply embedded compute device using proprietary transport
protocols and backend systems that actually wanted to do something
interesting with the data. From the very outset we had the following 5
simple design goals for MQTT:

1 - Simple to implement.
2 - Provide a Quality of Service Data Delivery
3 - Lightweight and Bandwidth Efficient
4 - Data Agnostic
5 - Continuous Session Awareness

My intent through this discussion group to to expand on each of these
design elements and add additional levels of detail on each.

I have been following these discussion threads with great interest and
hope that now some of the initial activities to promote MQTT are
behind me I can focus on interacting with this group more proactivity.
I have used MQTT to solve problems across the entire embedded system
landscape, from real-time pipeline control systems in the SCADA space,
to automatic meter reading, to slot machine monitoring, to home
medical gateways and pretty much everything in between. Indeed, to a
certain extent I have a big hammer and every problem out there looks
like a nail, but MQTT is a pretty good hammer.

One thing that I would like to recognize and get out on the table at
the very outset is that MQTT is indeed a publish and subscribe
"Transport Protocol" that is very flexible. With that being the
premise we will be engaged in active discussion threads on the why/
where/what/how of MQTT versus every other protocol out there. But as
Andy has already indicated this forum is primarily setup to interact
on the technology, uses, technics, and infrastructures that use MQTT
as providing an end-to-end solution and not a forum to simply argue
the merits of one transport versus another. So although we can and
will look at MQTT as compared to other transport technologies, this
forum is not a venue for just simply pitting protocols against
protocols.

To make it even more interesting, we're spanning two very diverse
interest groups. One group is the designers and builders of embedded
systems (remember, our job is to encapsulate process knowledge in
embedded solutions) and we are a very special group with specific
skill sets. Then there is the other group of the IT centric audience.
This group could probably care less about the "how" of an embedded
infrastructure but just want to get their hands on it to do something
interesting with the data. I would like to welcome and invite both of
these audiences to a lively discussion forum!

So again, I'd like to WELCOME everyone to this group and I look
forward to interesting, informative, and constructive discussion
around MQTT to the ultimate goal of making our system solutions and
infrastructures easier and faster to implement. Oh, and indeed this is
yet another step in the plan Andy and I had put in place for world
domination :-)

In closing, I would like to extend a Very Special Thanks to Andy Piper
for both setting up this discussion group and helping to drive the
interest and interaction. Thanks Andy !!

Cheers, Arlen