Oh yes, so do I :-). And it's allowed by the MQTT 3.1.1
specification, so it's something we have to expect.
The edge case I was referring to was the "overlapping"
subscriptions, and using per subscription message handlers. You
probably never need overlapping subscriptions, and if you do, you
can use the default message handler.
Another question that springs to mind is, if you reinstantiate a
client object from persistent store, how do you reestablish the per
subscription message handlers? Calling the subscribe method again
is the obvious solution, but does the client try to optimize by not
sending the MQTT subscribe request again?
Ian
On 05/06/2015 03:03 PM, Marc L Cohen
wrote:
I know of at least one server
that does send the message to each subscription.
Marc L. Cohen
MessageSight Test/Development
Internet:mlcohen@xxxxxxxxxx
also at:teddybbear@xxxxxxx
(512) 286-5744 (T/L 363-5744)
FAX (512) 973-4293
Ian Craggs
---05/06/2015 08:59:15 AM---Hi Roger, good point :-) The
embedded client stops at the first match. But in
From: Ian Craggs
<icraggs@xxxxxxxxxxxxxxxxxxxxxxx>
To: paho-dev@xxxxxxxxxxx
Date: 05/06/2015 08:59 AM
Subject: Re: [paho-dev] Java client: per
subscription message handling callbacks
Sent by: paho-dev-bounces@xxxxxxxxxxx
Hi Roger,
good point :-) The embedded client stops at the first match.
But in that case I want to take every step to minimize
processing and resource usage, so it seems like the right thing
to do.
I guess if it's an edge case, it may not matter, as long as we
are clear what the behaviour is.
Let's see if we get any votes...
Ian
On 05/06/2015 02:47 PM, Roger Light
wrote:
Hi Ian,
I refer you to the first line of
your previous answer :) You're right, it would be undesirable
in that situation, but it's a bit of an edge case.
Cheers,
Roger
On Wed, May 6, 2015 at 2:42 PM, Ian
Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
Hi Roger,
in the case of a server sending out a message for each
matching subscription, this would result in a proliferation
of messages, which seems undesirable to me.
Ian
On 05/06/2015 02:39 PM, Roger
Light wrote:
Hi,
The Python client does this and
checks every callback filter to see if it matches, and
hence will deliver a single message to multiple callbacks
if they overlap. It will deliver the message to the
"global" callback if it does not match any of the filtered
callbacks.
Cheers,
Roger
On Wed, May 6, 2015 at 2:30 PM,
Marc L Cohen <mlcohen@xxxxxxxxxx> wrote:
What is the proposal for
deciding which subscription if the topic matches more
than one subscription and the server only sends one
message, or if it sends one per subscription?
Marc L. Cohen
MessageSight Test/Development
Internet:mlcohen@xxxxxxxxxx
also at:teddybbear@xxxxxxx
(512)
286-5744 (T/L 363-5744)
FAX (512)
973-4293
Ian Craggs
---05/06/2015 08:13:13 AM---I'm proposing to add per
subscription message handling callbacks to the Java
client.
From: Ian
Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx>
To: General
development discussions for paho project <paho-dev@xxxxxxxxxxx>
Date: 05/06/2015
08:13 AM
Subject: [paho-dev]
Java client: per subscription message handling callbacks
Sent by: paho-dev-bounces@xxxxxxxxxxx
I'm proposing to add per subscription message handling
callbacks to the
Java client.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=466579
This will mean having to parse and match the incoming
topics, as MQTT
does not send the subscription topic with each
message, but the topic on
which the original message was published. I have some
simple code that
does that in the embedded C++ client however.
Any thoughts or comments welcome, here or in the
bug....
Thanks
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Paho Project Lead; Committer on Mosquitto
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Paho Project Lead; Committer on Mosquitto
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Paho Project Lead; Committer on Mosquitto
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Paho Project Lead; Committer on Mosquitto
|