Re: Real-time access implementation section

thanks a lot Eric!

cheers,
Berna

2016-05-13 9:03 GMT-03:00 Eric Stephan <ericphb@gmail.com>:

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


-- 
Bernadette Farias Lóscio
Centro de Informática
Universidade Federal de Pernambuco - UFPE, Brazil
----------------------------------------------------------------------------

Received on Friday, 13 May 2016 12:52:35 UTC