thpfft has asked for the wisdom of the Perl Monks concerning the following question:

I think this may turn out to be a mime-type question, or something else equally ot, but real are maddeningly coy about the whole subject, so here goes. sorry if obvious or off-limits.

I have clip data, subtitles, languages, people, preferences and all sorts of gubbins held in a database and dished out by a perl app. Amongst its many outputs are fear, surprise, SMIL files and realtext (but the clips themselves are just referred to, wherever they might be).

It's pretty much complete, and working well, but there are two issues that i can't seem to get around:

Can anyone cast light on either of these silly problems?

The only solution i can think of is to write temporary files out to disk for each clip and subtitle set. This strikes me as kind of stupid, but it does address both problems and bring me vaguely back on topic: it's a Class::DBI / tt2 application, and could easily leave text files in public directories as a side-effect of filling out the html part of the page (in a Subtitles->url method, i suppose), replacing them only if they're out of date.

So: two questions. 1. Would that be Bad? and, 2. I can't be the only person trying to do this. Has anyone got a better way?

(Which reminds me: no, Smil.pm isn't the answer. It's roughly comparable to the output routines of CGI.pm, and i'm using the toolkit for that sort of thing.)

Thanks.

Replies are listed 'Best First'.
Re: returning smil and realtext on demand
by gt8073a (Hermit) on Dec 16, 2001 at 13:42 UTC

    this is completely off the top of my head with no testing done, so take it as an opinionated guess...

    the plugin complains that there is no way to handle files of type '.pl'. As far as i know i'm returning the proper mime-types: application/smil, and text/vnd.rn-realtext, and the files are obviously well-formed or they wouldn't play at all

    the plugin might not approve of a .pl suffix, before it ever checks the mime type. try using "additional path information" in the link( ie, link => "/path/script.pl/smilfile.rn" ). smilfile.rn can be named whatever you like( you can incorporate session id's, db row id's, etc. ), just try ending it with a correct extension.

    Will perl for money
    JJ Knitis
    (901) 756-7693
    gt8073a@industrialmusic.com

Re:(answer) returning smil and realtext on demand
by thpfft (Chaplain) on Dec 16, 2001 at 20:58 UTC

    Thanks to everyone for helpful /msgs and reply. It turns out that there aren't really answers to either question: the many-files nature of smil is a design feature intended to keep it agnostic about source formats, and while you can in theory supply data in the inline link format:

    <text src="data:[base64encodedanything];base64">

    none of the players yet support it.

    and the answer to question two, thanks to crazy, turned out to be explorer being dumb about mime-types. sorry for wasting your time with that one.

    this post is a bit redundant, i know, but i wanted to close the thread and leave something for later explorers. must write a howto if i survive this.