Re: [mosquitto-dev] [paho-dev] Java MQTT broker

[Andrea Selva <selva.andre@xxxxxxxxx>]

Defining bridging protocols and provide some MQTT networks monitoring
and management tools is great idea!

 Andrea

On Fri, Jan 24, 2014 at 11:10 AM, Paul Fremantle
<paul.fremantle@xxxxxxxxxx> wrote:
> There is some early support for TLS-SRP in bouncycastle which is one of most
> used open source implementations in Java.
>
> Paul
>
>
> On 23 January 2014 23:34, Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx>
> wrote:
>>
>> Hi Roger,
>>
>>
>> On 23/01/14 22:03, Roger Light wrote:
>>>
>>> Hi Ian,
>>>
>>>> The goal of RSMB, and I
>>>> believe Mosquitto (Roger, correct me if I'm wrong) is to be smaller
>>>> rather
>>>> than faster.  (If it can be both small and fast, so much the better!)
>>>
>>> This is basically correct and I think a good focus for the project. I
>>> do take a subtly different approach with Mosquitto which is to not shy
>>> away from adding features, but to make sure that they can be removed
>>> at compile time to ensure it is always possible to create a lean
>>> executable.
>>
>> Your approach is perfect from my point of view.
>>
>>
>>>> In any case, I'm in favour of Andrea contributing Moquette.
>>>
>>>  From what Andrea says we are aligned in our goals, so I agree.
>>>
>>> How close do we want interoperability/equivalency of the
>>> Mosquitto/Moquette to extend? A few examples - I provide support for
>>> TLS-PSK and will support TLS-SRP in the future. Neither of these are
>>> particularly widely used but are definitely useful. I'm not sure if
>>> they are easily available in the Java libraries, so should Moquette
>>> strive to provide support as well? Should they have a common config
>>> file format? I have been talking for a while now about moving away
>>> from the current flat file format to a lua based config file, and then
>>> extending to allow lua plugins in the future. There are also some
>>> options which may be more C oriented (the auth plugins for example)
>>> that wouldn't make sense in the Java context.
>>>
>>> My feeling is that neither of these points should be a sticking point.
>>> I'd be interested to hear your thoughts around the area.
>>
>>
>> My thoughts are ...  I would advocate compatibility where it helps the
>> different brokers collaborate in MQTT networks.  Where the function does not
>> affect collaboration, by all means use the best available for that platform,
>> or experiment.
>>
>> For example, supporting different flavours of TLS is great.  As long as
>> both allow TLS clients to connect at some common level it's fine.  As long
>> as we can bridge from one broker to another with a TLS connection of some
>> kind, it's fine.
>>
>> Where I would suggest compatibility:
>>
>> - bridging protocols (including where brokers might exchange useful system
>> information)
>> - a significant proportion of monitoring topics (because you could monitor
>> whole networks of brokers easily)
>> - the format of system error/log messages, alerts and events (again
>> because you could monitor whole networks)
>> - remote admin method (so you could administer whole networks of brokers)
>>
>> Where it might not matter:
>>
>> - initial configuration (but what if you wanted to deploy networks of
>> brokers?)
>> - plugin interfaces (like security).  If the plugins have to be written in
>> C for Mosquitto and Java for Moquette for instance, it doesn't really matter
>> if the interfaces are different, and following the standard for the platform
>> could make more sense.  If you could use the same language for both, the
>> balance could swing.
>>
>> Ian
>>
>>
>>
>> _______________________________________________
>> mosquitto-dev mailing list
>> mosquitto-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/mosquitto-dev
>
>
>
>
> --
> Paul Fremantle
> Part-time PhD student - School of Computing
> email: paul.fremantle@xxxxxxxxxx, paul@xxxxxxxxxxxxx
> twitter: pzfreo / skype: paulfremantle / blog: http://pzf.fremantle.org
> CTO and Co-Founder, WSO2
> OASIS WS-RX TC Co-chair, Apache Member
> 07740 199 729
>
> _______________________________________________
> mosquitto-dev mailing list
> mosquitto-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mosquitto-dev
>