- From: Bernadette Farias Lóscio <bfl@cin.ufpe.br>
- Date: Fri, 13 May 2016 09:51:47 -0300
- To: Eric Stephan <ericphb@gmail.com>
- Cc: Newton Calegari <newton@nic.br>, Annette Greiner <amgreiner@lbl.gov>, "public-dwbp-wg@w3.org" <public-dwbp-wg@w3.org>
- Message-ID: <CANx1PzwySA727YNTk-7u7E7bAqrRR2dqzv92XWVG7afHOmpdkQ@mail.gmail.com>
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