Re: [videoblogging] question

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@…>

> 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:

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: <>
File Thingie – PHP File Manager <>