<?xml version="1.0" encoding="UTF-8"?><rss
version="2.0"
xmlns:content="http://purl.org/rss/1.0/modules/content/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:atom="http://www.w3.org/2005/Atom"
xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
> <channel><title>Comments on: Sparring via FCC filings</title> <atom:link href="http://www.gizmolovers.com/2007/09/17/sparring-via-fcc-filings/feed/" rel="self" type="application/rss+xml" /><link>http://www.gizmolovers.com/2007/09/17/sparring-via-fcc-filings/</link> <description>TiVo, Slingbox, Android, Blu-ray Disc, and whatever other tech I feel like blogging about...</description> <lastBuildDate>Fri, 18 Sep 2020 20:50:00 +0000</lastBuildDate> <sy:updatePeriod>hourly</sy:updatePeriod> <sy:updateFrequency>1</sy:updateFrequency> <generator>http://wordpress.org/?v=3.1.4</generator> <item><title>By: megazone</title><link>http://www.gizmolovers.com/2007/09/17/sparring-via-fcc-filings/comment-page-1/#comment-12511</link> <dc:creator>megazone</dc:creator> <pubDate>Thu, 20 Sep 2007 16:20:03 +0000</pubDate> <guid
isPermaLink="false">http://www.tivolovers.com/2007/09/17/sparring-via-fcc-filings/#comment-12511</guid> <description>Technically it could be either - I&#039;d expect it to be over TLS/SSL if it were over the public network.  Probably using certs for authentication for added protection.  But insisting on using the private network seems like something the cable MSOs would want.</description> <content:encoded><![CDATA[<p>Technically it could be either &#8211; I&#8217;d expect it to be over TLS/SSL if it were over the public network.  Probably using certs for authentication for added protection.  But insisting on using the private network seems like something the cable MSOs would want.</p> ]]></content:encoded> </item> <item><title>By: HDTiVo</title><link>http://www.gizmolovers.com/2007/09/17/sparring-via-fcc-filings/comment-page-1/#comment-12464</link> <dc:creator>HDTiVo</dc:creator> <pubDate>Thu, 20 Sep 2007 12:44:00 +0000</pubDate> <guid
isPermaLink="false">http://www.tivolovers.com/2007/09/17/sparring-via-fcc-filings/#comment-12464</guid> <description>As long as its illustrative of a concept its OK.Would you expect that the communication would occur only over the coax to/from the cable head end, rather than over ethernet/internet? I figure cable would want that over their &quot;closed&quot; network.</description> <content:encoded><![CDATA[<p>As long as its illustrative of a concept its OK.</p><p>Would you expect that the communication would occur only over the coax to/from the cable head end, rather than over ethernet/internet? I figure cable would want that over their &#8220;closed&#8221; network.</p> ]]></content:encoded> </item> <item><title>By: megazone</title><link>http://www.gizmolovers.com/2007/09/17/sparring-via-fcc-filings/comment-page-1/#comment-12227</link> <dc:creator>megazone</dc:creator> <pubDate>Wed, 19 Sep 2007 19:43:17 +0000</pubDate> <guid
isPermaLink="false">http://www.tivolovers.com/2007/09/17/sparring-via-fcc-filings/#comment-12227</guid> <description>Actually, based on the technology, I don&#039;t think TiVo&#039;s proposal is a joke at all.  In fact, I think it is a pretty solid compromise.The CE vendors object to OCAP because of the heavy burden it places on them - it turns the set top boxes into &#039;fat clients&#039; which have to do some heavy lifting to host the OCAP platform.  It also forces design choices by requiring special buttons on the remote, etc.Conversely, the cable industry objects to DCR+ or any SOAP-style interface because it puts all the onus on them to develop and deploy new server-side software that does all the heavy lifting but leaves all of the display choices up to the CE vendors.HME is in the middle - the server does more of the work, but since it is Java based it could even be evolved directly from OCAP software.  It could be possible to develop OCAP software that can run on &#039;fat client&#039; boxes *or* on a server OCAP platform, producing a variation on the UI for HME.  Keep in mind that the entire OCAP TiVo port for Comcast and Cox was developed using the HME toolkit.  You can produce a sophisticated UI using TiVo&#039;s internal HME kit - it is much more evolved than the public kit.  (Which is another issue entirely.)This allows CE vendors to have fairly &#039;thin&#039; clients, while giving the cable vendors more control over the applications and presentation.It is a lot like the X Windows system from UNIX/Linux in functionality.  It may even be preferable for some CE vendors as both DCR+ and OCAP require more work on the part of the CE platform.And I stress again that TiVo is not proposing that HME &lt;i&gt;be&lt;/i&gt; the protocol, but that it can server as the &lt;i&gt;basis&lt;/i&gt; for a protocol.  The final protocol could, and probably would, see many changes.  And it would be standardized outside of TiVos control - which could actually be a good thing in and of itself.But it is DOA unless TiVo gets support from other industry players.</description> <content:encoded><![CDATA[<p>Actually, based on the technology, I don&#8217;t think TiVo&#8217;s proposal is a joke at all.  In fact, I think it is a pretty solid compromise.</p><p>The CE vendors object to OCAP because of the heavy burden it places on them &#8211; it turns the set top boxes into &#8216;fat clients&#8217; which have to do some heavy lifting to host the OCAP platform.  It also forces design choices by requiring special buttons on the remote, etc.</p><p>Conversely, the cable industry objects to DCR+ or any SOAP-style interface because it puts all the onus on them to develop and deploy new server-side software that does all the heavy lifting but leaves all of the display choices up to the CE vendors.</p><p>HME is in the middle &#8211; the server does more of the work, but since it is Java based it could even be evolved directly from OCAP software.  It could be possible to develop OCAP software that can run on &#8216;fat client&#8217; boxes *or* on a server OCAP platform, producing a variation on the UI for HME.  Keep in mind that the entire OCAP TiVo port for Comcast and Cox was developed using the HME toolkit.  You can produce a sophisticated UI using TiVo&#8217;s internal HME kit &#8211; it is much more evolved than the public kit.  (Which is another issue entirely.)</p><p>This allows CE vendors to have fairly &#8216;thin&#8217; clients, while giving the cable vendors more control over the applications and presentation.</p><p>It is a lot like the X Windows system from UNIX/Linux in functionality.  It may even be preferable for some CE vendors as both DCR+ and OCAP require more work on the part of the CE platform.</p><p>And I stress again that TiVo is not proposing that HME <i>be</i> the protocol, but that it can server as the <i>basis</i> for a protocol.  The final protocol could, and probably would, see many changes.  And it would be standardized outside of TiVos control &#8211; which could actually be a good thing in and of itself.</p><p>But it is DOA unless TiVo gets support from other industry players.</p> ]]></content:encoded> </item> <item><title>By: HDTiVo</title><link>http://www.gizmolovers.com/2007/09/17/sparring-via-fcc-filings/comment-page-1/#comment-12216</link> <dc:creator>HDTiVo</dc:creator> <pubDate>Wed, 19 Sep 2007 18:46:37 +0000</pubDate> <guid
isPermaLink="false">http://www.tivolovers.com/2007/09/17/sparring-via-fcc-filings/#comment-12216</guid> <description>The FCC definitely does need to step in. That process is in the early stages now. Cable will say NO until no becomes a problem or threat to them, which only the FCC can create.Your last 4 paragraphs really hit the mark on the overall issue. However, TiVo is now the camel trying to put its nose under the tent.TiVo&#039;s proposal is a complete joke. Suddenly TiVo should become the maker of Windows for the STB. :oy:Using HME is as absurd as the excessive OCAP demands. As you point out with the examples of other standards, a much simpler universal system could be adopted.TiVo&#039;s audacity is amazing. Perhaps they didn&#039;t intend a serious proposal but merely an illustration. For credibility I hope that is it.</description> <content:encoded><![CDATA[<p>The FCC definitely does need to step in. That process is in the early stages now. Cable will say NO until no becomes a problem or threat to them, which only the FCC can create.</p><p>Your last 4 paragraphs really hit the mark on the overall issue. However, TiVo is now the camel trying to put its nose under the tent.</p><p>TiVo&#8217;s proposal is a complete joke. Suddenly TiVo should become the maker of Windows for the STB. <img
src="http://www.gizmolovers.com/wordpress/wp-includes/images/smilies/icon_surprised.gif?9d7bd4" alt=':o' class='wp-smiley' /> y:</p><p>Using HME is as absurd as the excessive OCAP demands. As you point out with the examples of other standards, a much simpler universal system could be adopted.</p><p>TiVo&#8217;s audacity is amazing. Perhaps they didn&#8217;t intend a serious proposal but merely an illustration. For credibility I hope that is it.</p> ]]></content:encoded> </item> </channel> </rss>
<!-- Served from: www.gizmolovers.com @ 2026-04-15 11:23:08 by W3 Total Cache -->