RE: Issue with "bytes" Range Unit and live streaming

HI there,

> Switching to HLS or DASH is not an option for every application, of course.
> And that certainly implies an additional layer of complexity when one just
> wants to provide access to a progressively-updated representation.

[TL] Yes, Understood, that this is not for all cases a solution.

> 
> Media streaming aside, there's always been awareness of progressively-
> updated representations in HTTP (IMHO). All we're really trying to do with
> this draft is enable a Range request that accommodates progressively-
> updated representations. I see this as a simple oversight with the bytes
> Range Unit that we're trying to remedy in a least-impactful way - one that
> many people have recognized but has not yet been addressed by an RFC.

[TL] Yes, I think that I understand your use-case and your proposed now. I don't have a strong opinion, whether to solve the use-case on HTTP layer or not. 

> 
> Happy Wednesday,
> 
> cp
> 
> >
> > From: phluid61@gmail.com [mailto:phluid61@gmail.com] On Behalf Of
> > Matthew Kerwin
> > Sent: Wednesday, April 20, 2016 10:17 PM
> > To: Thorsten Lohmar
> > Cc: ietf-http-wg@w3.org
> > Subject: RE: Issue with "bytes" Range Unit and live streaming
> >
> >
> > On 21/04/2016 6:14 AM, "Matthew Kerwin" <matthew@kerwin.net.au>
> wrote:
> >>
> >> On 21/04/2016 5:37 AM, "Thorsten Lohmar"
> <thorsten.lohmar@ericsson.com> wrote:
> >>> Hi Craig,
> >>>
> >>>> What *is* missing is the ability to get a continuous byte range on
> >>>> live content that starts at an arbitrary offset and the ability to
> >>>> directly jump to the live point.
> >>> Yes, and there are two solutions to the issue:
> >>> A. Enable it on HTTP Layer through the definition of a new range
> >>> request method B. Enable working with existing HTTP procedures, i.e.
> client can workout the precise byte offsets.
> >> C. Use a different URL (e.g. a ?start= query parameter). It's less optimal
> for caching, but it works today without any new specs..
> > Sorry, that's B(ii) isn't it.
> >>> BR,
> >>> /Thorsten
> >>>
> >> Cheers
> 
> 
> --
> 
> craig pratt
> 
> Caspia Consulting
> 
> craig@ecaspia.com
> 
> 503.746.8008
> 
> 
> 
> 
> 
> 
>

Received on Wednesday, 20 April 2016 22:24:05 UTC