Re: Real-time access implementation section

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
----------------------------------------------------------------------------