OCAP- Who is capping whom?

Discussion in 'TiVo Coffee House - TiVo Discussion' started by Justin Thyme, Jan 13, 2006.

  1. HDTiVo

    HDTiVo Not so Senior Member

    5,556
    0
    Nov 27, 2002

    Advertisements

    It was always a good night when Manilow was on the Carson Show, but I never saw him in concert. I have seen Neil Diamond and Neil Young, but never the latter did I see on Carson.

    I got a Manilow greatest hits CD two years ago from a friend who worked at Sony - seems they give out CDs there like individually wrapped hard candy. So that is another - free! - way to get music which one can manage to put on an iPod.

    Anyway, precisely: how inconvenient is it to get - as of right - iTMS onto a non-Apple device? That is the important question since Apple offers an opportunity to do it. If it is ridiculously impractical, that's an issue certainly from the consumer standpoint (esp. the initial decision to buy) and perhaps a legal issue as well. Is the iTMS software unreasonably tied to the Apple hardware, such that there is unfair interference with the consumer's rights to use the music; and are there other circumstances in the market that give Apple an unfair position, for example allowing it to exclude competition either from the music buying or music player markets?

    The telephone experience taught the valuable lesson that long distance access codes are a poor way to offer competition in LD. Important not to forget that lesson in the cable arena.

    DT-DC is describing the machinations pretty well above. It is a negotiation over not well defined meanings in the law. Remember what I mentioned much earlier about meaning and wording - each party ascribes a meaning to the wording of the statute. A negotiated deal will satisfy each party that the terms fit the wording satisfactorily and that each has gotten enough of the total available spoils.
     
  2. Justin Thyme

    Justin Thyme Contra sceleris

    3,306
    1
    Mar 29, 2005
    I have made my proposal of "closed but public" standards for interoperability. I heard you ask questions about whether people could pick and choose and I answered that. But I didn't hear objections.

    Regarding government dictating standards: I have written earlier on this and I think we are in violent agreement. Everyone has their own vision of what the standard should be. And we each have some feature we would pound our fist on the table about- Firewire :D or Component out HD ;) - whatever.

    Some standards are essential, sure. For basic operation of an economy government has a role there in creating the standards necessary for a foundation for commerce (uniform weights and measures, food quality, rules of the road-antitruct, etc.). I just don't see the argument why government needs to be involved here in the definition of what the standard actually is.

    My working proposal has been this:

    3) Get out of the arbitration of standards business. Not precipitously- after Cablecard multistream and integration ban is complete. HDTV for Disks is getting hammered out without government intervention. Very big interests with very big axes to grind have come into play. All sorts of similar issues with interactivity and OS dominance. If government were involved like they have been involved in the cablecard initiative, we would be seeing the first bd or hddvd players not in 2006, but in 2016, and the standard would only apply to some subset of HD players- as the POD standards only apply to cable.

    So what would the rules be? Well (and of course everyone will say this ;) )- the rules required by statute (ahem- yes- my interpretation of statute- I recognize other interpretations are legitimate):

    Carriers must promptly comply with the interpretation of the 1996 telecom act that access by third party navigation devices to programming and services means access to the substantial majority of programming and services- only omitting those that are technically not feasible to be supported by third party devices. Carriers means all carriers.

    Access by a third party mechanism means just that- a third party mechanism must have the access necessary to be able to create a competitor navigation mechanism to the carrier provided mechanism. That means that, aside from security functions, the third party must be able to manufacture a third party device without reliance on local carrier provided mechanisms.

    The Carriers may each define the access mechanisms "the API" however they like, they may define formats and protocols however they wish. They may change the protocols however they wish so long as they do not disable legacy third party devices. They may not define formats and protocols in such a way that the technologies used make the third party dependent on the Carrier (or companies affiliated with the carriers) to operate.

    Carriers must eat their own dogfood. The API, whatever it is must be the api that the carriers use to deliver their services and programming.

    If CEA vendors don't like the protocol because it came from a closed standard, they don't like the computational model that it forces, then tough. If portions of the API are technically or financially impossible for a third party to implement, or a new API was not made public in time to create a competitive offereing to an MSO product that took advantage of it, or they require onerous behaviors (playing of Manilow music) then that is a case for FCC punitive action.

    The principle I state here has precedent- it is not a new remedy. It has been used successfully with Microsoft. The DOJ agreement provides for the employment of 3 full time engineers to verify that the APIs that Microsoft uses in its applications do not make use of non public OS system calls or semantics.

    This mechanism of requiring APIs be made public is a mechanism that could be applied to any "fiefdom" where interoperability was used as a mechanism of product tying. With applications in music players, Cell phones, and operating systems for interoperating CE devices. Yeah, I am talking about pissing off Microsoft, Apple, and Verizon/Sprint/Tmobile. It's not that I have a grudge against the carriers in particular. This proposal is an equal opportunity offendor, because it will promote competition. Of course all of them will hate it because as we all know the key to brilliant business models answers the question on how you will close out your competition (legally). Interoperability games are certainly not new- there was International Salt Co. v. United States where the bastards in 1947 wanted to require only that their salt tablets be used with their machines, or countless other interoperability/tying schemes.
     
  3. HDTiVo

    HDTiVo Not so Senior Member

    5,556
    0
    Nov 27, 2002
    Too what extent can the government get out of the standards business? If each Cable operator used a different interface, would not this be a hardship for CE? Imagine NYC with Cablevision in the Bronx, TWC in Manhattan, someone else in Jersey. What would the retail shelves have to look like, or how thick would the 3rd party devices have to be to work with any cable plant?

    How were the cable modem (DOCSIS) and DSL modem standards reached?
     
  4. smark

    smark Well-Known Member

    12,338
    847
    Nov 20, 2002
    Denver, CO
    DOCSIS was created by CableLabs.
     
  5. Justin Thyme

    Justin Thyme Contra sceleris

    3,306
    1
    Mar 29, 2005

    Advertisements

    As smark pointed out earlier, they use a lot of common head end equipment, so my crackpot thinking here is that it is like interaction with video. At first people are writing into video buffers directly (direct manipulation of Cable server apis). Later, as it becomes more sophisticate, it probably becomes more like video card drivers where you talk to virtualized functions written by a third party that grooves on writing such things that talk to Motorolla DAC-6000's or SciAtl equipment. They sell their driver to whoever has cablecard support- Apple, Microsloth, Sony, Tivo. This makes it easy to send an update down to the DVRs when the System administrator mucks around with the configuration, altering the interaction timings slightly.

    It's still a work in progress proposal because if it is an API approach the huge portion of the service burden is off the provider. For example in the current scheme if you are certified as Cablecard 1.0 compliant Host, then the carrier Must function with you. Their techs have to come out and have to figure out why their network is not working properly with a compliant host and card.

    So support costs shift to the third party box supplier. If they can show they were making legal api calls using proper semantics etc, then maybe they would be entitled to charge the support cost back to the carrier. In my experience with system apis, it is generally the third party apps that are doing highly illegal things with the api- not the system messing up.**

    I say the burden is off the provider because you probably only get certified for the basic security, low level functionality of recieving and sending packets, getting authenticated, and getting "shut off" (account access to the network terminated due to non payment). I don't see how you certify a high level third party app like a Guide that is simply using the API is "correct". See what I mean? I know that you used to be able to get your App Windows 95 certified, but that only meant that you followed particular rules they were looking for- well behaved use of new structures like the registry, not grabbing handles of other peoples windows, and dicking with them etc. Good citizen stuff- not actually doing anything horrifying like walking the code and verifying you weren't doing undocumented crud. It just isn't realistic to certify such complex apps, except with a general test suite.

    So I can see support costs would be a force that would persuade CE companies to move closer to the cablecos and actually ask for a more comprehensive spec/ certification process. But market forces and not government fiat would force that.

    **There was a good example of this on a Blog site of an old time Microsoft engineer from the systems group. Hilarious stories. One story was that when XP was in beta, it "broke" SimCity- Get this, it crashed on XP because the code assumed it was OK to access memory it had released- you could do that under certain conditions in win98, but in XP you get a protected memory violation- so guess what MS does- they actually tweak XP when SimCity is running so that it can do this thing which was highly illegal under win98 and well established programming practice),
     
  6. classicsat

    classicsat Astute User

    17,877
    0
    Feb 18, 2004
    Ontario Canada.
    They'd be the same essentially.

    You wouldn't have the same STB in a Cablevision version, TW vesion iO version, Comcast version, and so on, you'd have just the one.

    It would assimilate to something useable on your cable system, the moment a CC is married to it. If you move from The Bronx to Long Island, you take the box with you, insert their card, and it will assimilate itself to the new system.
     
  7. classicsat

    classicsat Astute User

    17,877
    0
    Feb 18, 2004
    Ontario Canada.
    AFAIK, it is not really not that hard really.

    For PPVs:

    User: Tune PPV channel
    Tuner: Tuner PPV channel
    Card: Determine PPV status of customer and event. (PPV=allowed, credit=good, event=purchaseable)
    Card: If all postitive, request order, if neccesary use parental controls.
    Tuner>customer: Interact with customer to authenticate request
    tuner>card give okay to purchase.
    Card: If Authentication good, authorize event (with whatever authentication methind the access system utilises)
    User: Enjoy "The Fight"

    For a switched channel:
    User: select switched channel XYZ.
    Tuner>card tune switched channel
    Card>Tuner: tune to carrier:stream (virtual channel 1)
    Card>headend:set carrier:stream to switched channel XYZ.

    For VOD: Much like a switched channel, except headend will choose a stream from a server, and the user will be able to send pause, reverse, and forward commands.
     
  8. Justin Thyme

    Justin Thyme Contra sceleris

    3,306
    1
    Mar 29, 2005
    Right. Hey, it looks like a problem that requires lots of memory and a Virtual Machine.

    So let's require a proprietary Java VM so the Cablecos will have a boatload of options- like doing Larry Ellison's Network computer (NC) idea. With the cablecos of course providing the network and servers, and third parties building the NC's (cablecard 2.0 devices) for them.

    OTOH- say it is optional to the cablecard 2.0 spec and not required for PPV VOD and switched broadcasts.

    Naaahh. What if the CEA questions whether customers want to pay for faster processors and memory needed to run OCAP? What if we use a process where we let the market decide?

    Naaaah. Naive prattle. Nevermind.
     
  9. HDTiVo

    HDTiVo Not so Senior Member

    5,556
    0
    Nov 27, 2002
    Yes, but how did we reach the point where I can walk into a store and by any DOCSIS modem and plug it into any cable system and have my broadband? That concept is part of the necesary model for plug and play digital cable TV.

    But only if there is a follow through with creating such a standard. That's where the government comes in because market forces alone would not create this situation.

    Left to their own "devices" the cable cos. would change strategies to make a box bought for one system incompatible with another, leading to incentives to rent boxes from the cable co. rather than buy.
     
  10. dt_dc

    dt_dc Mostly Harmless

    2,013
    0
    Jul 31, 2003
    Northern...
    More later ... but ...

    The first thing I would do is point out (rather sardonically) that the OCAP specification meets every single one of your guidelines in this post.

    Under your proposal, CableLabs could just publish the OCAP specs and be done with the entire process (from the cable side at least ... doesn't address the 'all carriers' part of course).

    The second thing I would point out is that CableLabs wouldn't even need to publish the OCAP specification. Under your proposal, all they would need to do would be to publish (or rather point to) the DVB specification for data broadcasting
    http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=7555

    I will admit that making a third party device based on the DVB data broadcasting spec alone would be technically rather difficult ... and therefore financially expensive. But not impossible.
     
  11. Justin Thyme

    Justin Thyme Contra sceleris

    3,306
    1
    Mar 29, 2005
    Not at all. It does not satisfy this paragraph:
    That includes carrier provided software necessary to do VOD and PPV.

    It not possible at this time to access VOD, or PPV functions without reliance on a Carrier supplied piece of OCAP code. If the Carrier provided data on how to manufacture this code, then they would comply. But if they provided the data on how to manufacture the code, then the manufacturer would not have to use OCAP. They could just emit the Server control codes that the OCAP bytecode emitted.
    Really. That is hardly in the precendent set by DOJ settlement with Microsoft on published APIs. Would it have been sufficient of Microsoft to simply point to Intel Pentium assembler instruction set to show Oracle what "API" that SQL server was using to access their other product, Windows NT?

    Let me make it plain. There are two different entities. Windows NT is to Cableco Head end servers AS Microsoft SQL server is to Cableco controlled navigation devices that currently do PPV and VOD. They currently do this without OCAP using an API that is closed but not public. All that is necessary is to publish that they use in current products.

    That is all. This is not a complex proposal requiring decades of negotiation. Just publish what protocol they are using right now. It must not be any big secret, because their engineers appear to be able to manipulate it just fine.

    So I am confused how you think that either of your points apply.
     
  12. Gregor

    Gregor Wear Your Mask! TCF Club

    58,933
    5,529
    Feb 18, 2002
    Interesting discussion here, but I believe the intent of having to use the OCAP supplied code to do the communication is to avoid having a consumer-supplied device that's not quite compliant break the network. It wouldn't be hard to imagine such a non-compliant device breaking something and causing a large outage. Consider this on Super Bowl Sunday and you've got a huge problem.

    Otherwise the cable company would have to certify every device that they would allow to run on their network, which would be a tremendous effort. Since all the cable companies headends are often not running the same revision of software, you'd end up with a headend-specific list of supported consumer supplied equipment. Remember, too that that consumer device may never update it's code once shipped, so it becomes a maintenance nightmare as these devices age.

    Think of the OCAP code as providing an interface to the cable network, where the interface is on the consumer device, not on the cable network.
     
  13. dt_dc

    dt_dc Mostly Harmless

    2,013
    0
    Jul 31, 2003
    Northern...
    The next thig I'd point out is that your general ideals and principals is pretty much exactly what the FCC vocalized in thier first report and order on the subject.

    Now, the FCC didn't formalize these ideals into regulations yet. For cable (still not meeting your "All Carriers" ideal) ... they told CableLabs to come up witht their "API" and then everyone could discuss whether (or not) it fit these ideals.

    Many of the things you left until "after the fact" are the exact things that are / have been discussed since then. For example, exactly what is (and is not) technically possible or fiscally prohibitive ... what is "onerous behavior" ... exactly what type of "access" needs to be available to create a "competitive product" ...

    If the FCC had put these ideals into regulation at the start ... well, we'd probably be exactly where we are now which is figuring out whether (or not) the "API" meets the ideals ...

    Things like "technically or financially impossible" ... are never black and white. Everything is technically and financially possible ... it's a matter of balancing technical "possibilities" with resources ($$$, time, etc.)

    For example, scrambled analog content. The FCC / CEA / CableLabs went through this exact same process with scrambled analog content.

    CableLabs has "The CableLabs API" which allows access to scrambled analog content. They say it's expensive and will take a long time to implement on the headend ... but ... once done the CEA should be able to make navigation devices for scrambled analog content at minimal cost.

    CEA says that CableLabs' API is not as expensive or difficult to implement on the headend as cable says it is. However, it is very expensive to implement in navigation devices. If it's implemented, no one is going to make them. But there's "The CEA API" which isn't that expensive on cable ... and will make navigation devices much cheaper / easier to make. If done this way, the CEA will be able to make navigation devices.

    CableLabs of course says that "The CEA API" is near-impossible (technically and financially) to implement on the head-end. Not impossible ... it can be done. BUt at great cost. And, they also say that once done, "The CEA API" really doesn't make navigation devices as easy to implement as they say it will.

    The ironic part here is the small cable operators. "The CableLabs API" and "The CEA API" are both too expensive for them to implement. If they could afford to start moving those scrambled analog channels to digital, they would be anyway. They can't ... they also cant' afford either solution. The big cable operators that can afford either solution are getting rid of scrambled analog anyway via market forces.

    CableLabs, CEA, and FCC eventually mostly agree to "defer" scrambled analog untill later. Cable can still use it, but there's not going to be an API yet for it. Maybe later. The market will probably take care of the issue on its own. I say mostly because, there's still a few parties that would like to see an API for scrambled analog.

    Now, lets look at this "after the fact" as you propose. "The CableLabs API" is published. Big cable operators (mostly) get rid of scrambled analog anyway. A few big operator plants still have it ... but not many. Those that do support "The CableLabs API". Small cable operators are the ones mainly using scrambled analog ... but they can't really afford the cost to implement "The CableLabs API" either. CEA doesn't make any boxes that support "The CableLabs API" because they say it's too expensive and most cable operators with scrambled analog don't support it anway. CEA brings a claim to the FCC that 1) "The CableLabs API" is financially impossible to implement for them, and 2) many cable operators don't use it anyway, seeking the "punitive damages" you refer to.

    So now, the FCC has to get right back in to the "arbitration of standards" business figuring out who is wrong and who is right. Are the small operators right that it's too expensive for them to implement? If so, do we offer examptions to some operators? If so, where do we draw the line? Is the CEA right that "The CEA API" is a better, cheaper solution?

    You're not getting out of the arbitration of standards business at all. You're just deferring it for someone to do later. The exact same issues that the interested parties are discussing / arguing / negotiating / agreeing to now (without much FCC intervention at all) are the exact same issues that someone would have to decide later, after the fact. After cable publishes and implements their API ... someone would have to arbitrate these disagreements.

    Why isn't preferable to arbitrate them now ... especially when the parties are (mostly) in agreement without FCC arbitration at all.
     
  14. dt_dc

    dt_dc Mostly Harmless

    2,013
    0
    Jul 31, 2003
    Northern...
    I would call the current API "public". Ok, you have to pay to get at them. But, for the most part, "what they use" is available. Note that this isn't because of any FCC actions at all. It's because of standard market forces. The cable companies insisted on it.

    If the cable companies bought Scientific Atlanta Guide Data software on the headend ... they didn't want to be locked in to Scientific Atlanta software on the client. They wanted to be able to write their own ... or get others to do it. Which, by the way, many people have done.

    You, or I, or anyone else can write software that talks to all of cable's guide data head end software ... or VOD head end software ... or iPPV head end software. Like I said ... you gotta pay to see the specs. But this isn't the issue. "Not public" APIs are not the issue.

    So why don't we have "commercial availability of navigation devices" right now?

    The issue is portability / standardization.

    I can write software that will talk to BrandA guide data servers (which some cable companies use). I can write software that will talk to BrandB guide data servers (which some cable companies use). I can write software that will talk to BrandC guide data servers (which some cable companies use). I can write software that talks to any one of these ... but not the others. I can even write software that will talk to all three. Of course, writing software that talks to all three is significantly more expensive than writing software that talks to just one. Same thing goes for VOD servers ... switched broadcast servers ... iPPV servers ...

    In fact if you pick a (well known) brand of any of these I can probably find you multiple clients from different vendors for any of them.

    The issue is portability / standardization.

    Now, as noted earlier in the thread ... there aren't a whole lot of major competitors in these spaces. You can break most down in to two or three major ones. Of course, there's also lots of minor ones.

    And the competitors don't even always have their own "API". "Use our better/faster VOD head-end software and you can still use the C-Cor VOD client" is a very attractive sales pitch for new entrants to the field.

    Again ... all due to standard maket forces.

    But ... there ARE different APIs.

    Cox uses BrandA in some places ... and BrandB in some others. Comcast uses BrandB in some places ... and BrandC in others. Time Warner uses BrandA in some places ... and BrandC in others. And of course, a few places use D, E, or F.

    So, as a CE company do you support BrandA and not the others. Or BrandB and not the others. Or BrandC and not the others. Things of course get even more complicated when you're talking BrandA, BrandB, and BrandC for various components (Guide, VOD, etc). Or do you try to support them all ... very expensive and you're going to be competing against cable-supplied software that only has to support one ...

    Your "closed but public" API exists right now. CE companies say that they can't afford to manufacture / market products that will work on all cable systems. On the other hand, they don't see a market for products that work on some Cox systems (but not all) even if the product also works on some Comcast systems (but not all) and some Time Warner systems (but not all).

    Cox, Time Warner, Comcast etc. of course have no problem supporting / providing the less expensive clients that will only run on one (or a few) cable systems.

    Portability was a major point of discussion early on in the preceedings ...

    You keep comparing cable to Microsoft ... I would say a better comparison is to PC makers. Current PC makers ship PCs that run Windows, MacOS, Linux, Solaris, etc. You're asking the PC makers to ship PCs so that the same applications run on any PC they ship. So that third parties can write software that will compete with the software Dell bundles with its PCs. A bonanza for application developers (they get to easily write apps that will run on any PC). But you're basically imposing a government-mandated standardized OS ...

    How do you address portability? How do you define "Carrier" above? Does all of cable have to support the same API? Or is it acceptable for Cox, Comcast, and Time Warner to support different APIs (even better, different APIs in different markets). And don't forget about Verizon. Verizon is technically a 'cable company' too. Do they have to support the same 'cable' API or do they get to choose another one?
     
  15. dt_dc

    dt_dc Mostly Harmless

    2,013
    0
    Jul 31, 2003
    Northern...
    Not true. You, me, and anyone else can write software to access VOD from a C-Cor server (that some cable comapnies use). You, me, and anyone else can write software to access VOD from a Tandenberg VOD server (that some other cable companies use). We can do this without using OCAP at all. OCAP does not prevent this at all.

    The Tandenberg and C-Cor VOD server APIs are publically available.

    OCAP allows you and me to build a box that will run the cable-provided software that will then access VOD regardless of whether they are using a Tandenberg VOD server or a C-Cor VOD server. They (cable) know what servers they are using so ... they will provide software that knows how to talk to it. They might provide their own software, or client software provided by the same company that makes their VOD server, or they could even provide software from a third party (that knows how to talk to their VOD server). The key is ... they know what brand VOD server they are using so ... they only have to provide software that can talk to one brand of VOD server.

    But OCAP does not prevent us (you and me and anyone else) from writing software that talks to these servers directly. We could sell it to the cable companies (to put on their boxes). We could put it on our own box and sell it directly to customers. We could make the navigation / selection / GUI / user-visible funtionality exactly how we wanted too. We could integrate other third-party content (internet downloads, whatever) in there. We would basically have the flexibility to make that VOD client app look / feel / behave however we wanted too.

    The problem is ... if we're making software to put on our own box and sell directly to the customers ...

    Do we support Tandenberg servers? Do we support C-Cor servers? Do we support only one and try to explain to the customer why VOD works on some cable systems ... but not others. Or do we try to support both which would be expensive. It would definately be more expensive than software that only supports one. And we are competing against software that only has to support one. And while Tandenberg and C-Cor might have a very large market share ... they are not the ONLY ones with VOD servers (with their own APIs). There are others.
     
  16. classicsat

    classicsat Astute User

    17,877
    0
    Feb 18, 2004
    Ontario Canada.
     
  17. classicsat

    classicsat Astute User

    17,877
    0
    Feb 18, 2004
    Ontario Canada.
    This is what the proverbial "stub" OCAP applet does.

    The cableco integrator designs an interface applet to interface between the network and the STB UI, using "standard" UI hooks. The "hook" inteface wood have standard ports to order PPVs, call up a switched channel, or call up a VOD program and control it, and get a guide list of VOD and PPV events.

    The STB software can make their own isolated VOD or whatver applet if they want, or seamlessy integrate VOD/PPV/Switched channels into their STB UI. Or they can choose to use a full OCAP applet, it is up to the sovtware writer for that STB.
     
  18. dt_dc

    dt_dc Mostly Harmless

    2,013
    0
    Jul 31, 2003
    Northern...
    Yes ... proverbial.

    AFAIK, there are no standard "stub" OCAP interfaces defined and cable isn't really putting any on the table. Please correct me if I'm wrong.

    Yes, if there were ... that would provide a solution for what (some members) of the CEA are looking for ...

    OTOH ... even if cable doesn't provide any now ... market forces and all could very well provide them going forward ...
     
  19. Justin Thyme

    Justin Thyme Contra sceleris

    3,306
    1
    Mar 29, 2005
    Well it is an unprovable point.

    Standardization sounds like a really really hard problem until you are talking about over 20 million customers using the same type of VOD server. I was assuming the kind of heterogeneity problem you are talking about until Smark suggested that the opposite was the case, and that the virtualization was serving unrelated goals. Smark is in a position to know for a fact whether this is so, and I have no reason to doubt his credibility.

    So I'd like to understand more about your assertions about this big complicated world that is crying out for that the god of virtualization can fix for us.** Are you asserting that today, Panasonic or Sony or Samsung or anyone else could produce a Cablecard box that can access VOD/PPV services for say Comcast's use of a particular VOD brand of server and the only thing stopping them is the cost of paying for the access to the manuals? I'm not sure why that is not a practical business opportunity when you look at the number of customers involved.

    Because I see no such initiatives, I am skeptical of this assertion, so perhaps I am misunderstanding what is "publically available" today, or I misunderstood the picture of uniformity that Smark drew. On the former, I believe you are professionally familiar with these types of system installations. I can imagine that having a manual on a VOD server would be quite useless if you did not have information on how the server was configured.

    Even if we were to constrain ourselves to particular vendors in particular localities, is it true to say that all such information necessary for an implementation that would work in a particular locality is available?

    **Don't get me wrong- I am a big fan of virtualization stuff. I DO question whether non virtualization is practical today even in isolated localities with current public information. I DO question whether the cableco requirement that third party vendors run cableco navigation mechanism locally is conformant to interpretations reflecting the intent of the 1996 telecom act. IF the former is not practical, and the later can be interpreted legitimately to not be conformant, then maybe what we need is new FCC commisioners that will get serious about enforcement of 1996 Telecom Act, not new laws.
     
  20. Justin Thyme

    Justin Thyme Contra sceleris

    3,306
    1
    Mar 29, 2005
    Nope. Oracle didn't have to pay any extra money to learn what the formerly nonpublic APIs to Windows were. Public means.... public. You go the the Comcast Seattle Website and it has the api calls, the timing semantics, and example code for changing from one VOD channel to the next. No big deal. Just hire some technical writers to document what all the internal engineers know.

    No decade long wait. I hear what you are saying- it is real complicated, it involves computers, cableco networks are complex, there is no standard, it will be chaos. This is exactly what the priesthood of the Mainframe said when micros happenned along. For every PC, it was a different hardware and software architecture. And it was absolute chaos.

    But guess what- the apis were public and entrepeneurs rose to the occaision.

    If it is way too hard for Sony or Samsung to build a service network that stays on top of changes that require updates to STBs, then fine. They need not show up at the party.

    I can tell you if I had a web page in the city where I live that I would write the dang interface code. And I wouldn't need any bureaucrat paper pusher theorizing what the best way for me to write that ideal code on an ideal theoretical machine.

    When you on the other hand cast my proposal as "Ideal", it implies impracticality or that I am promoting some particular ,model of how computers should interact. Well- what is the vision of interaction? Nope- all I am saying is whatever the model that these particular companies have in particular localities-

    Just Make Whatever It Is Public

    That's an ideal? What model of interoperability am I promoting? What theory? What feature wishlist? I'm proposing no such ideals here.

    And what is impractical about it? I heard you say it's complex and impractical. I heard you say that its hard to define what games are and are not permissible that the carriers may play with the public info. You know what- you could spend a decade imagining what sorts of BS people could come up with. Let's not wait another decade trying for an imaculate conception. Just publish the dang info and deal with the BS as it comes up. Yet there is something impractical if you don't clutter up a simple "make it public" directive without a bunch rules attempting to deal with hypothetical situations which may never arise.

    I challenge the characterization that this is somehow an idealistic (impractical) proposal. If it were true the microcomputer revolution would never have happened.

    Offhand, I would say that the current scheme of requiring 10 years to produce the cablecard spec that only half way works is demonstrably a delusionally idealistic and unworkable scheme for high tech industries.
     

Share This Page

spam firewall

Advertisements