Re: data streams

Dave

>Script developers ony need to know the object model for the sensor and
display. The details of the underlying protocols are dealt with
>automatically by the server platform. For this to work, we need a standard
way to describe data streams as part of the data model for "things".

What would be the scope of this definition? Only a model of the stream
(metadata), or will also propose an api to handle streams. In this later
case, I would suggest to take a look at what the reactive programming
community has been developing, for example in RxJS (which is very similar
to how java 8 handles streams)



---------------------------
Pablo Chacin
CTO
SenseFields SL
Tlf (+34) 93 250 45 98
Gran Via 674, principal 1º
08010 Barcelona, Spain
http://www.sensefields.com

En compliment del que disposa la Llei Orgànica de Protecció de Dades
15/1999 i el seu reglament, Sensefields, S.L. us informa que les vostres
dades personals seran tractades i incorporades als nostres sistemes
informàtics i documentals, dels quals és titular  aquesta empresa. Si voleu
podeu exercir els drets d'accés, rectificació, cancel·lació i oposició
previstos a la llei, adreçant un escrit amb la fotocòpia del DNI a
Sensefields, S.L. Gran Via Corts Catalanes, 674 Principal 1ª - 08010
Barcelona (Barcelona) o bé per e.mail a info@sensefields.com

Aquest missatge va dirigit, de manera exclusiva, al seu destinatari, i
conté informació confidencial i privilegiada. En cas de rebre aquest
missatge per error, prego que ens ho comuniquin de forma immediata
mitjançant resposta per correu electrònic, o a través del telèfon 0034 93
250 45 98, i procedeixi a la seva eliminació.

En cumplimiento de lo dispuesto en la Ley Orgánica de Protección de Datos
15/1999 y su reglamento, Sensefields, S.L.  le informa que sus datos
personales serán tratados e incorporados a nuestros sistemas informáticos y
documentales, de los que es titular esta empresa. Si desea puede ejercer
los derechos de acceso, rectificación, cancelación  y oposición previstos
en la ley, dirigiendo un escrito con la fotocopia del DNI a Sensefields,
S.L. Gran Via Corts Catalanes, 674 Principal 1ª - 08010 Barcelona
(Barcelona) o bien por e.mail a info@sensefields.com

Este mensaje va dirigido, de manera exclusiva, a su destinatario y contiene
información confidencial y privilegiada. En caso de recibir este mensaje
por error, ruego que nos lo comuniquen de forma inmediata mediant respuesta
por correo electrónico, o a través del teléfono 0034 93 250 45 98, y
proceda a su eliminación.

In compliance with The Law of Data Protection Act 15/1999 and its
regulations, Sensefields, S.L.  informs you that your personal data will be
processed and stored in our computer systems and documentaries owned by
this company. If you can exercise your rights of access, rectification,
cancellation and opposition under the Act, by writing the photocopy of ID
to Sensefields, S.L. Gran Via Corts Catalanes 674 Pral 1ª 08010 -
(Barcelona) (Barcelona) or by email to info@sensefields.com

This message was directed exclusively at the recipient and contains
privileged and confidential information. If you receive this message in
error, I beg to inform us immediately by reply email or by phone 0034 93
250 45 98, and proceed to their elimination.

On Wed, Jun 3, 2015 at 11:25 AM, Dave Raggett <dsr@w3.org> wrote:

>
> On 3 Jun 2015, at 09:04, Magnus Olsson <magnus.olsson@ericsson.com> wrote:
>
> Streams sounds like a very useful thing to support :-)
>
> - For the multiple sinks, why not use a pub sub broker as the identified
> source of the stream that way any number of sinks can attach to that
> pub-source. Seems to me that setting a proxy output value to point to a
> single output is a limitation that might result in someone creating an
> upstream proxy to split to multiple sinks.
>
>
> This is a question of the underlying API and data structures. For files,
> for example, an open file handle can only be read by a single client. If
> you want several clients to read the stream, then they each need to open it
> individually so that they have their own stream handles/stream objects.
>
> I completely agree that pub-sub protocols provide a good solution to
> streaming to multiple clients, which is why I advocate support for bindings
> to MQTT and XMPP (as examples of such protocols), but this is at a
> different level of abstraction.  We need to distinguish between the data
> model exposed to scripts and the bindings to the transport protocols, as it
> is important to decouple these to simplify scripting amongst other reasons.
>
> Any thing should be able to redirect any aspect of their source (defined
> by its meta description) to a nearby pub-sub proxy service. Still that
> could be an "on device" (localhost) broker, a home broker, a service
> provider broker or a public broker etc.
>
>
> The Web of Things Framework allows you to have multiple proxies for the
> same thing, and you can define new things that transform streams etc.
>
> It seems reasonable to me to have use case such as one part of the stream
> for the snapshot, another for the live view a third for data analysis, a
> fourth for a remote tele medicine, a fifth for a emergency monitoring
> function etc.
>
> - Even discrete value type of sensors could be handled as a stream if only
> given long enough time to observe
>
>
> To keep simple use cases simple to script, we need a data model where
> values are simple object properties, e.g. a floating point number
> corresponding to a temperature reading. This will change over time as the
> corresponding physical value changes.  This is applicable where you are
> only interested in the current reading.
>
> Note that you can define a data model where an event is generated to
> signal a change to a value. This raises the question of what constitutes a
> significant change, but that is something for applications to determine.
> Such events enable applications to implement their own history buffers.
>
> A data logging application has different requirements, in that you want to
> record the history of changes along with the times that they occurred. This
> involves a different data model where you can ask for a the value at a
> specific time or for the sequence of changes in a given time interval. This
> is a common enough meme that it deserves to be supported by the server
> platform rather than requiring apps to implement logging and querying
> themselves.
>
>
> —
>    Dave Raggett <dsr@w3.org>
>
>
>
>