Re: [Totem] Browser plugin gstreamer

[Bastien Nocera <hadess hadess net>]

On Tue, 2008-08-19 at 21:17 +0300, Felipe Contreras wrote:
> On Tue, Aug 19, 2008 at 8:21 PM, Bastien Nocera <hadess hadess net> wrote:
<snip>
> > Do you think website designers will use your plugin if it doesn't
> > support the basics? Your plugin would need to support enough features
> > for website developers to consider using it, otherwise they'll target
> > WMP or Quicktime, or possibly VLC if they're nice people.
> 
> The context was non-emulating plugins.

Website designers need to target a specific mime-type/plugin that will
support a documented API. You can either create your own mime-type, thus
plugin API, and nobody will use it (look on Google for the number of
sites supporting application/x-totem-plugin). Or you can emulate widely
used plugins from other platforms.

Which mime-type would your plugin support then?

<snip>
> > It's already been discussed in bugzilla. Supporting playlists in
> > GStreamer is far too low down in the stack. Feel free to use the code in
> > totem-pl-parser to write an element and the API needed on top. But I
> > still don't see what that would buy us.
> 
> We are talking about a browser plugin for other multimedia
> applications, not totem.

What would those be? Give me a use case.

<snip>
> > It's called security. It's only got to hurt once for it to be a problem.
> > Take a look at MPlayer's and Xine's recent CVE advisories, or even
> > Flash's. For it to be crafted to hurt might be unlikely, but crafted to
> > crash on some systems doesn't even have to be on purpose.
> 
> Yeah, I know. It's even more secure to don't bother developing it in
> the first place.

That's very helpful...

> >> If all the code is contained in the plugin then packaging becomes very
> >> easy: one file. Which I guess helps for plugin autoinstallation.
> >
> > Why would it help plugin auto-installation. Whether it's one or three
> > files shouldn't make a difference to the installer (whatever it could
> > be), and Totem's browser plugin is already shipped by default on a good
> > number of distributions.
> 
> Automatic installers don't have access to /usr/share/totem or /usr/libexec.

I don't plan on supporting those.

> >> >> > $(libdir)/libbaconvideowidget.so.0.0.0 (shared with Totem itself)
> >> >> > $(pkgdatadir)/mozilla-viewer.ui
> >> >> > $(pkgdatadir)/fullscreen.ui (shared with Totem itself)
> >> >> >
> >> >> > That comes in under a meg stripped...
> >> >>
> >> >> I guess it depends on what is required.
> >> >
> >> > Can certainly be smaller if you remove some of the compatibility
> >> > plugins.
> >>
> >> I meant, if you are interested in simple playback (not emulating other
> >> plugins) then ideally the plugin can be contained in one file.
> >
> > And which websites would use your plugin?
> 
> http://commons.wikimedia.org/

In which case exactly?

> >> Personally I would like to be able to install a plugin in my
> >> "~/.mozilla/plugins" directory, and not require anything else. Adding
> >> an application in the same directory to be run as a separate process
> >> seems reasonable too, but adding those .ui files doesn't appeal me.
> >>
> >> All this discussion makes me wonder about some ideas:
> >>
> >> a) Is it possible to pack all the "compatibility plugins" into a single plugin?
> >
> > No, because browsers expect one plugin per shared library. You can't
> > have a single shared library have multiple names, descriptions (unless
> > you employ gross hacks including symbolic links...).
> 
> But you could have one plugin that handles different object types.

Yes, that's easy.

> >> b) Would it make sense to have a configuration to choose an
> >> application other than "totem-plugin-viewer"?
> >
> > Why? The IPC API is very ad-hoc as well, and will probably change (or
> > have to change) to support more features.
> 
> That was the original question from Mark Trompell: so other multimedia
> players don't have to write their own browser plugin.

No, he asked about the video widget to be shared.