Re: Real-time access implementation section

I wasn't sure but here are links that could be used:

Server-sent Events, https://en.wikipedia.org/wiki/Server-sent_events
WebSocket, https://en.wikipedia.org/wiki/WebSocket
EventSourceAPI, https://www.w3.org/TR/eventsource/

Cheers,

Eric


On Fri, May 13, 2016 at 4:40 AM, Bernadette Farias Lóscio <bfl@cin.ufpe.br>
wrote:

> Hi Eric,
>
> Thanks a lot for your contribution! I just made the updated and a pull
> request on github.
>
> Do you think that we should include references or links to Server-sent
> Events, WebSocket, EventSourceAPI?
>
> cheers,
> Berna
>
> 2016-05-13 8:03 GMT-03:00 Eric Stephan <ericphb@gmail.com>:
>
>> Okay,
>>
>> I reworded a few items to make them sound a bit better.
>>
>> Cheers,
>>
>> Eric
>>
>> A possible approach to implementation is for publishers to configure a
>> web service that provides a connection so as real-time data is received by
>> the web service it can be instantly made available to consumers by polling
>> or streaming.
>>
>>
>>
>> If data is checked infrequently by consumers, real-time data can be
>> polled upon consumer request for the most recent data through an API.  The
>> data publishers will provide an API to facilitate these read-only requests.
>>
>>
>>
>> If data is checked frequently by consumers, a streaming data
>> implementation may be more appropriate where data is pushed through an
>> API.  While streaming techniques are beyond the scope of this best
>> practice, there are many standard protocols and technologies available (for
>> example Server-sent Events, WebSocket, EventSourceAPI) for clients
>> receiving automatic updates from the server.
>>
>> On Thu, May 12, 2016 at 4:05 PM, Eric Stephan <ericphb@gmail.com> wrote:
>>
>>> Based on the article Annette (Thank you Annette!) shared,
>>>
>>>
>>> Below is my recommendation for an Implementation:
>>>
>>>
>>> A possible approach to implementation is to configure a web service that
>>> provides a connection so as real-time data is received by the web service
>>> it can be instantly made available by polling or streaming.
>>>
>>>
>>>
>>> If data is checked very infrequently real-time data can be polled upon
>>> consumer request for the most recent data through an API.  The data
>>> publishers will provide an API to facilitate these read-only requests.
>>>
>>>
>>>
>>> If data is checked frequently streaming data may be more appropriate
>>> where data can be pushed through an API.  While beyond the scope of this
>>> best practice, there are many standard protocols and technology (for
>>> example Server-sent Events, WebSocket, EventSourceAPI) for clients
>>> receiving automatic updates from the server.
>>>
>>>
>>>
>>> To engender greater credibility, in addition to data itself, publishers
>>> can classify and document error conditions and anomalies in the data. This
>>> will enhance real-time applications' ability to interpret and convey
>>> real-time data quality to consumers.
>>>
>>> On Fri, May 6, 2016 at 6:44 AM, Newton Calegari <newton@nic.br> wrote:
>>>
>>>> Hi Annette,
>>>>
>>>> I liked the article and I think we could suggest those other approaches
>>>> to cope with real-time on the Web.
>>>>
>>>> Newton
>>>>
>>>> Em 06/05/16 09:48, Eric Stephan escreveu:
>>>>
>>>> Hi Annette,
>>>>
>>>> This is a really good article, it makes some really valid points that
>>>> are worth sharing in the BP.
>>>>
>>>> I can see your point on the streaming/polling.
>>>>
>>>> Eric S
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On May 6, 2016, at 12:42 AM, Annette Greiner < <amgreiner@lbl.gov>
>>>> amgreiner@lbl.gov> wrote:
>>>>
>>>> I like what this guy has to say and how he defines things.
>>>> http://www.leggetter.co.uk/2013/10/28/history-background-benefits-use-cases-realtime.html
>>>> I also think we should talk about streaming vs. polling, server-sent
>>>> events and web sockets. I don't find the push/pull breakdown very helpful.
>>>> -Annette
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On May 5, 2016, at 1:48 PM, Eric Stephan < <ericphb@gmail.com>
>>>> ericphb@gmail.com> wrote:
>>>>
>>>> Hi Newton and Annette,
>>>>
>>>> Here is my suggestions for rephrasing the implmentation section of the
>>>> Real-time access.
>>>>
>>>> What do you think?
>>>>
>>>> Cheers,
>>>>
>>>> Eric S
>>>>
>>>> A possible approach to implementation is to configure a web service
>>>> that provides real-time or near real-time accessibility to transient data.
>>>> Depending on the requirements data may be pushed or pulled.
>>>>
>>>>
>>>> Streaming data can be pushed through an API.  Publishers will need to
>>>> provide documentation describing the structure.   Publishers may choose a
>>>> variety of algorithms to provide data.  For instance, first-in-first-out
>>>> (FIFO) stream (e.g. head, tail, body) requires consumers to properly
>>>> interpret the head, body, and tail of stream. Publishers may choose other
>>>> algorithms such continually overwriting a cache to provide the latest
>>>> status information.
>>>>
>>>>
>>>> Real-time data can be pulled upon consumer request for the most recent
>>>> data through an API.  The data publishers will provide an API to facilitate
>>>> these read-only requests.
>>>>
>>>>
>>>> To engender greater credibility, in addition to data itself, publishers
>>>> can classify and document error conditions and anomalies in the data. This
>>>> will enhance real-time applications' ability to interpret and convey
>>>> real-time data quality to consumers.
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
>
> --
> Bernadette Farias Lóscio
> Centro de Informática
> Universidade Federal de Pernambuco - UFPE, Brazil
>
> ----------------------------------------------------------------------------
>