Surely the best place to start would be the BBC Trust's website and read the Canvas documents.
http://www.bbc.co.uk/bbctrust/search/search.shtml?scope=bbctrust&uri=%2F bbctrust%2F&q=canvas&go.x=47&go.y=4 If you search hard, and I admit its hard, then you can find that the consultation on Canvas closed on 1st September. BBC people who are actually directly involved in Canvas should wait until the Trust announces its decision before talking about it - otherwise they'd be in trouble. But there's no reason why people on this mailing list can't talk about it. Unless someone on this list knows something confidential! As for when the Trust intends to announce its decision, well that seems obscure at the moment. -----Original Message----- From: owner-backst...@lists.bbc.co.uk [mailto:owner-backst...@lists.bbc.co.uk] On Behalf Of Mr I Forrester Sent: 14 October 2009 19:03 To: backstage@lists.bbc.co.uk Subject: Re: [backstage] Re: Sky hits out at Project Canvas Just to be clear, I'm not saying we're not allowed to say anything, its just not clear what we can be said. I've heard so much about Canvas over the last year, I'm not even sure whats public, whats hear-say and whats actually secret (if anything) :) As some one said its a hot potato. I've just started re-reading Jonathan Zittrain's "the future of the internet and how to stop it." - http://futureoftheinternet.org/. If you've not read it, go and download it or buy it now. And been thinking since watching Micromen #b00n5b92, (http://www.bbc.co.uk/programmes/b00n5b92) about the balance between the pc and ce (consumer electronics). This is at the very start of Zittrain's book. Sorry for the length.... "two inventions-iPhone and Apple II-were launched by the same man, the revolutions that they inaugurated are radically different. For the technology that each inaugurated is radically different. The Apple II was quintessentially generative technology. It was a platform. It invited people to tinker with it. Hobbyists wrote programs. Businesses began to plan on selling software. Jobs (and Apple) had no clue how the machine would be used. They had their hunches, but, fortunately for them, nothing constrained the PC to the hunches of the founders. Apple did not even know that VisiCalc was on the market when it noticed sales of the Apple II skyrocketing. The Apple II was designed for surprises- some very good (VisiCalc), and some not so good (the inevitable and frequent computer crashes). The iPhone is the opposite. It is sterile. Rather than a platform that invites innovation, the iPhone comes preprogrammed. You are not allowed to add programs to the all-in-one device that Steve Jobs sells you. Its functionality is locked in, though Apple can change it through remote updates. Indeed, to those who managed to tinker with the code to enable the iPhone to support more or different applications, Apple threatened (and then delivered on the threat) to transform the iPhone into an iBrick. The machine was not to be generative beyond the innovations that Apple (and its exclusive carrier, AT&T) wanted. Whereas the world would innovate for the Apple II, only Apple would innovate for the iPhone. (A promised software development kit may allow others to program the iPhone with Apple's permission.) Jobs was not shy about these restrictions baked into the iPhone. As he said at its launch: We define everything that is on the phone.... You don't want your phone to be like a PC. The last thing you want is to have loaded three apps on your phone and then you go to make a call and it doesn't work anymore. These are more like iPods than they are like computers." On Wed, 2009-10-14 at 13:21 +0100, Mo McRoberts wrote: > Hokay, taking a slightly different tack-rather than moaning about the > bits of the proposal which appear incongruous, here's something more > tangible (and arguably useful). > > This is how I reckon it -should- work (and, obviously, is what I'm > speccing for Baird):- > > Assuming the technical specs for actual content formats and over-IP > transport protocols have been settled upon, what we're left with is > delivery of metadata and the UI to make it useful. Essentially, there > are two ways that metadata can arrive on a box; one is over the air, > the other is via an Internet connection. The same information's > carried in both cases. The supplier of the box would naturally be able > to predefine some subscriptions to metadata sources, but the principal > initial source in most cases would be OTA (whether it's carried by > Freeview, Freesat, Virgin, or Sky). > > This basic metadata would consist in the first instance of a set of > services. There's some potential for duplication here, of course, as > the same service metadata might arrive by way of different sources, > and a service might be listed both in the context of a service > offering (e.g., Freeview) or a broadcaster (e.g., the BBC). > Identifying the dups is fairly straightforward, though, assuming the > format of the metadata is sane. Each service listing contains a > location for the actual service metadata itself, as well as: > > * the various delivery mechanisms for the service and what form they > take, accounting for regional variations > > In the case of BBC 1, this would list each of the dvb:// URLs > applicable to the various regional broadcasts, as well as the > simulcast URL, the mobile SDP URL > > * preferred channel numbering > > This is a straightforward order-of-preference list, which may be > constrained by the STB vendor. BBC 1 could, for example, indicate a > preference for "1" and "101" in that order. In addition, for each > regional variant, there's a second list, so it might also indicate > that 974 is the preferred variant channel for "BBC 1 London". > > In terms of variations, the two tie up with one another: if there are > no available delivery mechanisms for BBC 1 Scotland, for example, no > attempt to assign channel 971 to it would be made. > > The service metadata carries the above, as well as details of the > programmes carried, which may include links to poster frames in > various resolutions, links to microsites and HTML-based interactive > apps, rich descriptions, and so on. The programme _may_ be an OTA > broadcast, or purely on-demand, or both. In either case, the metadata > can include information about when the programme is available > according to the different delivery media. This would allow a range of > different scenarios, from a programme which is aired but never > available for catch-up viewing, to the usual iPlayer-style setup where > catch-up is available for a limited period shortly after airing, the > less common scenario where the programme is available to download > immediately but will be aired at some point in the future, right down > to on-demand-only programmes which can be streamed or downloaded as > required, depending upon the available transports and protocols. > > In addition, an OTA broadcast could well include extensions to the > metadata in the transport stream-which could well be useful for > commercial broadcasters wishing to add additional features to > advertising, as well as correcting last-minute errors or omissions in > the previously-obtained metadata. > > Subscribing to a service manually would involve some kind of user > entry. DNS-SD would be used to reduce the typing required, though, so > if you were to subscribe to "freeview.co.uk", the STB would query for > PTRs to SRV records matching _msdf._tcp.freeview.co.uk (or whatever), > which work not dissimilarly to the _http._tcp DNS-SD discovery > mechanism. Fallback methods are trivial, though (e.g., HTTP request to > the root with a specific Accept: header). > > If you're a content-provider, it's mostly a matter of publishing the > metadata in the right place in the right formats. > > Unless I'm being dim, this-if specified properly, in technical terms, > plus some "thou shalt provide xxx feature in order to be able to call > yourself compliant and use the logo" would encompass Canvas's aims > without requiring:- > > a) a joint venture and the associated costs, ramifications, entry > requirements, and risk of accusations of gatekeeperism; > b) a mandated UI > > (sidenote #1: if it doesn't appear to encompass Canvas's aims, it > means I've either missed something in my reading of them, or in the > description above). > > (sidenote #2: obligatory mock-ups of what it could look like, but > noting that the specs don't define this: > http://emberapp.com/nevali/collections/nxtv-stb-mock-ups/ > ) > > What I can't figure out is why the above isn't sufficient. I realise > the BBC folks aren't going to be able to give an answer to that > question _but_ if there are any glaring errors or omissions in the > above, I would really appreciate it being pointed out! > > Answers on a postcard to the usual address... > > M. > - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/ - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
