I missed this discussion, being on
vacation last week in Montreal.
As stated in the Mosquitto proposal, the aim for an MQTT server in
C was to target the smallest environments, even where a JVM was
too big, or consumed too much of the available resources.
A Java implementation of something like Mosquitto/RSMB be would
complementary as it could serve the purposes of:
1) really nice integration into the Eclipse IDE, and
2) integration into the OSGi stack
although it wouldn't have to be quite as "KISS" as Mosquitto,
having a well defined scope (say MQTT and MQTT-SN protocols only)
would still be desirable, otherwise, as Paul says, we could end up
with just another message broker. And feature bloat.
As currently phrased, the Mosquitto proposal describes a C/C++
MQTT server implementation. I like that focussed scope - there
are well-defined boundaries. As it stands, a Java MQTT server
would be another project.
If the Mosquitto project were deemed to be a container for any
MQTT server, then the project proposal would have to be
amended. Paho contains MQTT clients in all languages, but a
server is a larger undertaking, so having a separate project for
MQTT server implementations in different languages does not feel
like overkill to me.
On 07/10/13 11:59, Paul Fremantle wrote:
ActiveMQ and its successor Apollo are both general
purpose message brokers. I think they are excellent choices in
many circumstances. I would also like to see MQTT support added
to other general purpose brokers, for example Apache QPid.
However, I would suggest that RSMB and Mosquitto implement
a different pattern that aligns very well with MQTT which is
the idea of a very small footprint broker that specializes in
MQTT. I think if we build any new work in Java we should aim
for this model. Otherwise it will just be YAMB (Yet Another
paho-dev mailing list