create new tag
, view all tags

A Generic Inline Media Plugin

Work in progress, under construction OK, it's in need of testing, But I seem to have a working ObjectPlugin. Documentation is not quite done, but for the adventurous, check out the attached zip (do the usual, unzip in TWiki dir, turn on in configure). I'll endeavour to iron some of that stuff out and upload it soon. PG

Having just ironed out some of the bugs in the 2003 QuickTime plugin, it strikes me that it wouldn't be significantly harder to produce a single plugin which handles embedding all the various flavours of media out there, with minimal work from page creator (while retaining the ability to specify various params if you want). Default params are stored as preference variables, so end-users can modify them without having to edit the .pm file


Simple form:

%MEDIA{"SomeMovie.swf"}% - plugin determines from file extension that this is a flash movie and uses appropriate tags, filled with default values

Warning, important Note: We may have an issue with some (many?) plugins and not specifying dimensions - they don't work like <IMG> and detrmine the dimensions from the data, they just fall back to a plugin default, so I think the minimum you can ever specify is:

%MEDIA{"SomeMovie.swf" width="220" height="400" }%

A bit more complex:

%MEDIA{src="SomeMovie.mov" width="220" height="400" autoplay="false" controller="true"}% - plugin determines from file extension that this is a QT

Really complex:

(Of course, at some point, you get so complicated you might as well just use HTML)

%MEDIA{src="SomeMovieWithNoExtension" mime-type="video/mpeg" scale="223%" autoplay="false" controller="true" useplugin="WindowsMedia"}% - plugin attempts to get WMV plugin to play MPEG1

Possible Params:

Name Description Note(s)
src File name/path/URL of media file  
height height of file (do we assume pixels?)
width width (do we assume pixels?)
Play|AutoPlay Should the file start playing by itself?  
Controller display interface controls (play, volume, etc) may not be supported by flash
mime-type what the media is inline plugin is chosen on this basis, also reported to the plugin, if possible
pluginspage URL for where to get the plugin to play this media } I think we probably want to hard-code these as defaults, I can't see any use for varying them
codebase URL to get MS ActiveX for this media type
useplugin regardless of media type, use this plugin  
useW3C use <OBJECT> tag in generic W3C way, no <EMBED> tag  


  • Should this be a generic inline anything plugin - PDF, TeX, media ? (I think it should be engineered to be pretty extensible and agnostic)
  • At some point, you might want this to just roll into the magick that turns any .gif, .jpg, .png into an inline <img> tag

Basic pseduocode

  1. init values:
    1. Extract default values from pluginpage
    2. determine media type from file extension
  2. Overwrite defaults (inc. media type) from whatever passed params there are
  3. Populate a template set of tags for this media type with the params
    1. Probably involve a slight alteration of params to suit the plugin's syntax (e.g. does it want width="100px" or "100" )

-- PiersGoodhew - 06 Sep 2006

Good ideas here...

Possibly enhance the EmbedPlugin with this; it already has a generic name.

-- PeterThoeny - 10 Sep 2006

Please take a look at my comment to EmbedPluginDev

-- ThomasFreudenberg - 15 Sep 2006

Interesting thoughts indeed. My only immediate criticism would be that EmbedPlugin refers to the never-standardised "embed" tag. What I have begun working on is, in fact, an "object" plugin. If it detects a particular media type, it will use the recommended HTML from the plugin provider, if not (or if you tell it to stay W3C compliant) it uses the very simple, generic form of the OBJECT tag (which I actually think would work pretty well in everything but IE - I mean it will break in navigator 4, but who's using that?). The OBJECT tag can embed java, media, svg, it can act as a client-side include, pretty useful.

Or I should say "seems to be pretty useful". I'm still some way from being able to even begin testing the plugin ...

The parameterised include is very cool, but suffers from not being able to detect the media type, which was just about the top goal for me in this endeavour ...

-- PiersGoodhew - 18 Sep 2006

Please see Internet Explorer Eolas changes and the Flash plugin to learn what happens with Explorer and object or embed tags. The solution is to write these tags using javascript. In that case it would be safer (at least for Flash) to use existing code like SWFObject, which is widely used.

-- ArthurClemens - 18 Sep 2006

Hi Piers, what do you mean exactly with "but suffers from not being able to detect the media type". If someone want's to publish some media things, doesn't he already knew what he wants to embed ? In this he will use/he can use the right include topic e.g. "EmbedObjectQT", "EmbedAppletQT", and so on. Also it would be possible to use those kind of "java-scripting" to detect right things. I didn't really see the benefit of a separate plugin. Do I miss something ? I guess it would be much easier to administrate a twiki installation if some of the existing addons and plugins were also designed like ParameterizedIncludes. All changes are made by topics and that's native wiki behavior. Wouldn't that be better ?

-- ThomasFreudenberg - 18 Sep 2006

Hi Thomas. No, I don't think you're missing anything, I just think maybe we were born different wink

  • The advantage to having the plugin handle the media type is:
    1. reusability - one plugin handles them all
    2. portability - if you change something embedded from one thing to another, all you do is change the filename
    3. convenience - for the above reasons, you don't need to decide in advance which plugin to use
  • Yes, you could implement some detection using javascript. (I'm also leaning towards just using the object tag and letting the browser decide - there is a "generic" way to use it and it will work in modern browsers (I think) ) (it's also just an accidental fact of life that I'm a lot more proficient at perl than javascript)
  • I can see the advantages to having the plugin on a wiki page (I certainly intend to have all defaults as variables on the plugin page) but
    • right now, plugins are the way everything else is done in TWiki, if Edinburgh moved to a lot more parameterized incls, then that's the way this functionality should be handled
    • I'd argue that actually tinkering with how a plugin works is more "under the hood" than just straight page editing anyway, so having it hidden from normal users is not as big a disadvantage as it might seem.
    • You could also argue the converse: perhaps there should be a way of viewing and editing the perl source for all TWiki .pm's thru TWiki

-- PiersGoodhew - 18 Sep 2006

Hi Piers, I got your points. So I will try to do my best in making a ParameterizedInclude Example to embed a media object. I think it would be interesting what kind of problems such a solution will have and what kind of advantages. Also I think we could participate from each other by being born different smile

-- ThomasFreudenberg - 19 Sep 2006

Indeed we should, at the current rate of progress, I think you might get there first. I drove over my laptop a few days ago. d'oh!

-- PiersGoodhew - 22 Sep 2006

See the box at the top. A beta ObjectPlugin is available to try. Tested on Safari, Firefox and WinIE. on IE the html embed fails, naturally.

My daughter wants to type her name: eloise minnie.

-- PiersGoodhew - 14 Oct 2006

Thanks for sharing this plugin. How about creating the plugin topic and attach it there? That way people are more likely to discover it.

BTW, the zip file contains spurious ._.DS_Store and .DS_Store files. On SHORTDESCRIPTION it might be better to be specific' "arbitrary content" could mean anything.

-- PeterThoeny - 14 Oct 2006

The plugin howto's say "upload your tested plugin" which kind of implies to me that the thing is a little more finished than this one is. (Couldn't see a clear "beta phase" process for TWiki plugins). I can test on a range of browsers tomorrow, but I can only test it on TWiki's running under OSX.3.9. Did it work for you?

I guess I can just put it up as-is, but it didn't seem quite right...

Re: the DS_Stores: naughty Mac OS X, I'll kill 'em next time. Re: arbitrary content - you can embed just about anything on a standards-compliant browser - media, html, java, pdf. On IE you're stuck with wmv, qt, flash.

-- PiersGoodhew - 15 Oct 2006

I did not try out the plugin, I just looked at the files in the package. Open source development motto is release early and often. If you mark the beta state in the plugin topic you set the proper expectation. So I think it is OK to create the plugin topic already.

What I meant, "arbitrary content" could be associated with text, files, tables, bullets, images etc. How about something like: Embed arbitrary media objects into TWiki pages, such as flash, pdf, qt, wmv and more

-- PeterThoeny - 15 Oct 2006

Resource forks and Finder DB's removed and topic created. See ObjectPlugin.

Regarding "arbitrary" content - you can embed all that on a Mozilla. On iE you need the CLASSID param, which is only added for the three detected media types. I'll keep working on a sentence that can convey all that ...

-- PiersGoodhew - 17 Oct 2006

Topic attachments
I Attachment History Action Size Date Who Comment
Compressed Zip archivezip ObjectPlugin.zip r1 manage 64.1 K 2006-10-14 - 04:15 PiersGoodhew  
Edit | Attach | Watch | Print version | History: r14 < r13 < r12 < r11 < r10 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r14 - 2006-10-17 - PiersGoodhew
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.