kevin at kismith.co.uk
Mon Nov 10 14:29:47 UTC 2014
[Sending a few mails to try to rekindle this discussion]
On Tue, Sep 30, 2014 at 5:20 PM, Hund, Johannes
<johannes.hund at siemens.com> wrote:
> My $0.02:
>> > >> My core concern here is that this spec
>> >> (http://xmpp.org/extensions/inbox/iot-events.html) is designed such
>> >> that one entity can publish events, to which assorted other entities
>> >> can subscribe, which fundamentally sounds like pubsub, for which we
>> >> have some coverage in XEP-0060. IOT-Events comes up with a
>> >> new syntax for both the subscribing and the publishing from that
>> >> described in XEP-0060, and I'd like to see if there is common ground
>> >> for sharing syntax (and, ideally, semantics).
>> >> I note at this point that re-use of XEP-0060 syntax would not imply
>> >> the use of central pubsub services on components or servers. In
>> >> IOT-Events, a Thing is its own (IOT-Events)pubsub service; I'm
>> >> interested in seeing if they could be their own (XEP-0060
>> >> subset)pubsub service instead.
>> > I like this general approach!
> I fully agree that the best way IMHO is generalizing XEP-0060 and keeping as close as possible to the regular semantics
>> The way I read IOT-Events, it was a single subscription, but I'm hoping
>> Peter or other IOT folks can weight in here much more usefully than I
>> can. Fortunately we have the mechanisms in xep60 to cope with either.
> Maybe I am misundertanding it, but I think single-subscriptions would restrict some use cases.
Could well be, yes. 60 will support either model, though, I think (at
least - I don't think it misses anything), we would just need to
decide which to go with (assuming we want to tightly define the xep60
subset in use for IoT, so as to minimise complexity for small
> An example use case is if you have different subscriptions with different timely resolutions, maximum ages etc.
> This can happen when you have an entity that has several applications running which do require different event notifications.
> I would not restrict it to single-subscription given it does not cause an unreasonable overhead.
Sounds reasonable, thanks.
More information about the Standards