Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] Matching messages to subscriptions in the java client

Hi David,

> The obvious thing would be to implement the wildcard matching in my code
> and re-run the match client-side,

that's the only option available with the client API as it stands -
but it isn't too onerous. I have some sample code, well a one-liner,
somewhere that converts the MQTT topic filter into a java regular
expression - which can then be matched against the received topic.

> but I'm wondering if there's a better
> way, or if such a matcher at least belongs in the client api?

All of the clients we've developed have traditionally used the single
callback pattern. It is only more recently when I've worked on other
language clients (such as javascript) where it felt more natural to
allow per-subscription callback functions to be provided by the
application.

One of the goals of the java/c clients was to provide the core
functionality of a client without burdening it with lots of extra
features, whilst retaining the ability for applications to wrap the
client and add those features.
I don't think this should be in the core client, but it would just
take a pair of subclasses to MqttClient and MqttTopic to provide this
ability - whether that is part of Paho or not, I don't know.

Cheers,
Nick


On 14 August 2012 21:29, David Illsley <david@xxxxxxxxxxx> wrote:
> Hi,
> I'm looking at the java client, and wondering how best to associate a
> message received to a particular subscription (or possibly
> subscriptions). In particular, I'd like to wrap the existing API to
> allow individual callbacks for each subscription, but simply keeping a
> map of the subscription topic filters and comparing with the received
> message topic obviously doesn't work because the filter can include
> wildcards.
>
> The obvious thing would be to implement the wildcard matching in my code
> and re-run the match client-side, but I'm wondering if there's a better
> way, or if such a matcher at least belongs in the client api?
>
> Cheers,
> David
> _______________________________________________
> paho-dev mailing list
> paho-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/paho-dev


Back to the top