Home > All Posts > Individual Post
Post #1213

Re: [videoblogging] question

By Andreas Haugstrup | "Andreas Haugstrup" <videoblog@...> | andreashaugstrup
September 16, 2004 | Post #1213 | Topic #948

I'm going to cut away my own words in this reply. I hope people can still follow the thread. On Thu, 16 Sep 2004 13:29:40 -0400 (EDT), Lucas Gonze <lgonze@...> wrote: > On Thu, 16 Sep 2004, Andreas Haugstrup wrote: > I think that I don't know the difference between hypertext and > hypermedia. > Can you enlighten me? Adrian probably has some nice definitions at hand, but I'll have to do with Wikipedia. Hypertext is just a subset of hypermedia. See: <http://en.wikipedia.org/wiki/Hypertext&gt; <http://en.wikipedia.org/wiki/Hypermedia&gt; Hypermedia in the sense of video and audio would mean that the audio/video would have the "hyper" qualities of hypertext (ie. linking). > The general algorithm I'm using is say that you want to publish a > document > containing an assertion that FOO is a response to BAR. I picked HTML as > the most trivial way to do that. Relying on HTML when we are talking audio and video content is something I don't like to do. If nothing else the because you run into the permalink trouble. You would have one URL for the HTML and one for the video. And how do you find the correct video in the HTML file? It's best just to get rid of the wrapper all together (ie. assign the permalink directly to the video file). > Well, here I think there's no answer that really grabs me. Requiring > Quicktime parsers all over the place just to find out this simple issue > of > what the video is responding to is a tough path to take. But think of the possibilities! The data would be located along with all the other metadata at the begining of a file so you would only need to fetch the first couple of kilobytes of a video. It would be no different than fetching an HTML file. > I appreciate the > reason why you're thinking of including metadata with the file itself, > but > at the same time I believe that needing to parse each and every potential > wrapper format is very very unlikely to work. You need that for text also. The difference is that there is only one format of text (HTML). I would love to have everyone use SMIL for example as it would make parsing files for links just as easy as it is with HTML. So all that's needed is one common format to present audio and video hypermedia. W3C says it's SMIL, but hardly anyone is using it. > Sure you can. You search on response:to="URL of my video", then view the > HTML of the page containing that link. And that's the problem in a nutshell. A response:to solution would be a waste of computing power, time and money on an immense scale. With pingbacks you simple ask the URL to return a list of incoming links. It's simple and easy. The workload is on the content creator since he has to send pingbacks whenever he creates new content. For the person this would only costs a little bit of time, and whatever bandwidth it costs to send the small pingback packages. With a response:to solution you would have to seach *the entire world wide web* every time you wanted to see incoming links to an URL. The workload is on whoever requests the list (or whoever he asks to compile the links [eg. Google]). Compared to the work required to send pingbacks this requires a vast amount of power. Only the big players with factory halls filled with servers would be able to handle this. Each document on the world wide web is only created once, so the time/energy it requires to send pingbacks is not really anything worth talking about. But requesting a list of links is likely to happen many many times more, and that's why it's such a complete waste to search through every single URL everytime someone asks for such a list. > But pingbacks have no better noise (read "spam") control than referrer > logging. There's no s/n problem right now because there's so little > actual usage. Yeah, they do. Pingbacks are requested from the author of a document. Already there they are better (no webmail system referers, not useless referers like URLs without a required query string, no duplicates [eg. with and without a trailing slash]). > Well, any search engine can do the job. Google, Feedster, etc. The data > remains decentralized, it's only the access points (like Technorati) that > are centralized. But with pingbacks *everyone* can be an accesspoint. With solutions like response:to or technorati only big players can be an accesspoint. I can't make a system that finds incoming links in a response:to system, but I can take advantage of pingbacks in a second. > This is an interesting solution. I'm sort of buzzed at the idea of > considering the HTML and video different representations of the same > resource. At the same time I don't yet buy it, since I doubt that in > reality the video and HTML will really represent the same resource. I thought about that for a long time. It works on paper, no doubt about that. You only add the <link> if the HTML presentation and the video file contains the same information. On the other hand I don't think authors are aware of the differences between HTML and video file being the same resource, and an HTML file with a video file embedded. Because the difference seems insignificant when you glance over it, but it has far reaching consequences. - Andreas -- Personal: <http://www.solitude.dk&gt; File Thingie - PHP File Manager <http://www.solitude.dk/filethingie/&gt;