[Standards] IOT-Events

Joachim Lindborg joachim.lindborg at sust.se
Thu Oct 9 09:53:52 UTC 2014


I agree in the need for multiple subscriptions. I have that in several
usecases.

 I would also adress the "keep it simple need" the xep 323 is very easy to
use and the need for events for small sensors are essential to
prevent extensive polling.
Demanding pubsub and forms notation to the devices adds a lot of complexity
to the implementor of the sensor implementor.

I could almost argue that the <subscription> stanza should be added to the
xep 323 for simplicity but a see the need for a separate namespace and
perhaps other usecases


*Regards*
Joachim Lindborg
CTO, systems architect

Sustainable Innovation  SUST.se
Barnhusgatan 3 111 23 Stockholm
Email: Joachim.lindborg at sust.se
<javascript:_e(%7B%7D,'cvml','Joachim.lindborg at sust.se');>
linkedin: http://www.linkedin.com/in/joachimlindborg
Tel +46 706-442270

2014-09-30 18:20 GMT+02:00 Hund, Johannes <johannes.hund at siemens.com
<javascript:_e(%7B%7D,'cvml','johannes.hund at siemens.com');>>:

> 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
> > completely
> > >> 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!
> >
> > Excellent.
>
> 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.
>
> 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.
>



-- 
*Regards*
Joachim Lindborg
CTO, systems architect

Sustainable Innovation  SUST.se
Barnhusgatan 3 111 23 Stockholm
Email: Joachim.lindborg at sust.se
linkedin: http://www.linkedin.com/in/joachimlindborg
Tel +46 706-442270
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20141009/06045245/attachment.html>


More information about the Standards mailing list