Re: WebSub query

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