Re: WebSub query

And, Nigel, we'd love to have BBC representation into the new Social Web Incubator CG! (I added Olivier to the thread; the other BBC guy I know.) That's where we'll explore what the next focus should be. Come help make it happen!

  -- Ann

Ann Bassetti

> On Nov 25, 2016, at 5:40 AM, Ben <ben@thatmustbe.me> wrote:
> 
> Hello Nigel,
> Thank you for the feedback.
> 
> The working group had been avoiding any real time use cases for the most part. My primary concern would be that it breaks all existing implementations. The spec is more focused on reduction of polling to a web site for example to get breaking news articles out to readers immediately without reader software constantly polling the site.
> 
> I can certainly see the value in some sort of real time spec like that, but I wonder if there is another existing spec more suited to it.  If not, this would be something I would love to see incubated in the new community group.
> https://www.w3.org/community/swicg/
> 
> As to the publishing section, it could probably use some clarification there.  Would something like this make it clearer? (I'm not an editor of the spec, but would be happy to take a stab at it here).
> "The hub and the publisher can agree on any mechanism to send or notify the hub of updated content, as long as the hub is eventually able send the updated payload to the subscribers as defined in Content Distribution" ( https://www.w3.org/TR/websub/#content-distribution )
> 
> Does this make things clearer?
> 
> Thank you again for the feedback,
> 
> Ben
> 
>> On Nov 25, 2016 6:17 AM, "Nigel Megitt" <nigel.megitt@bbc.co.uk> wrote:
>> Dear Social Web Working Group,
>> 
>> I just saw your recently updated https://www.w3.org/TR/websub/ spec.
>> 
>> It appears that the only URI scheme that is clearly supported for sending data back to subscribers is https: (or http:). Did you consider the possibility of supporting a WebSocket URI with wss: or ws: with a more realtime connection lifecycle model, rather than requiring a separate HTTP callback?
>> 
>> That would be very useful in a variety of use cases, for example messaging or status updates for real time events (e.g. sports game scores, electoral counts etc). The particular use case I have in mind is for live captioning/subtitling.
>> 
>> However I realise I may have somewhat misunderstood the intent of the spec: it would be very useful to have some more descriptive text in §5. Publishing. I see that the current wording "The hub and the publisher can agree on any mechanism, as long as the hub is eventually able send the updated payload to the subscribers." potentially allows for other possibilities, though I am not clear how the hub is expected to send the updated payload to the subscribers -  an HTTP POST to the subscriber callback URLs perhaps?
>> 
>> Looking forward to learning more about this interesting spec,
>> 
>> Kind regards,
>> 
>> Nigel
>> 
>> -- 
>> Nigel Megitt
>> Executive Product Manager, BBC Design & Engineering
>> Telephone: +44 (0)3030807996 
>> BC2 C1 Broadcast Centre, Media Village, 201 Wood Lane, London W12 7TP
>>