Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] On Paho's opinionated URI validation

I think parts of those changes are sensible. You're not missing anything, this is just code that could be improved. I think making tcp:// and mqtt:// synonyms makes some sense.

One thing I would note though, since MQTT-S (soon to be MQTT-SN) exists, you may want to rethink the mqtts:// as an alias for ssl:// ... that's a little more tricky.

In general the Paho Java client code for URI handling is very brittle right now. I raised this as a bug a while ago and I know Al made some initial changes.

One thing I would like to ensure is that whatever scheme is adopted, and your patch may contribute to changing (probably easiest to attach a patch to the existing Bugzilla report)... we should try to ensure that all of our language clients are equally capable of understanding that scheme.

There's no standard MQTT scheme today, although IIRC once upon a time, one of the IBM products did informally support one. I know that some of the other third-party clients out there have adopted their own, too (mqtt+nio etc). There is an IANA-assigned port number but currently officially listed by an old name (1883 = ibm-mqisdp, precursor name to MQTT, 8883 = secure-mqtt .... there's also mqtt listed as assigned to AndySC without a port number, but with a TXT record |Defined TXT keys: topics=<open topic to subscribe to for information>, eg topic=/info|). In my opinion, definitely something to be proposed for wrapping up in the OASIS work.

Thanks for raising this - useful as well in the light of the MQTT Interop testing discussion in another thread!


On Mon, Nov 4, 2013 at 7:00 PM, Michael Klishin <michael.s.klishin@xxxxxxxxx> wrote:
I maintain Machine Head [1] and work on a project that provides
applications with URI's to connect to an MQTT capable broker

I generally find Paho Java a pretty nice library but a couple of things
stand out as odd usability issues.

One of them is URI validation that Paho performs. Here's the exact
code that does it:

This raises two questions:

 * Why is there no standard mqtt:// scheme? This is very inconvenient for e.g. PaaS service providers that provide URI's that developers should use.
 * Why won't Paho accept tcp:// but not tcp:// (with a trailing slash)

tcp:// and tcp:// are technically two different URI's but it's
pretty easy to see how a user may provide either and expect the same result.

Am I missing something? Would a patch that makes Paho treat
both "" and "/" as valid paths be accepted? What about a patch
that makes "mqtt" an alias for "tcp" and "mqtts" an alias for "ssl"?
Just to make it clear: both will not introduce any breaking changes.

paho-dev mailing list

Andy Piper | Kingston upon Thames, London (UK)
blog:   |   skype: andypiperuk
twitter: @andypiper  |  images:

Back to the top