[xine-devel] xine plugin

[Zubin D. <zu...@ji...>]

I checked out the xine-plugin source and have been taking a closer look
at it.  I'm pretty new to xine and to GUI progreamming in general, so
don't hesitate to tell me I'm full of it... but I think I see a problem
with the current way in which things are being done -- it seems to me
that a new process will get forked for xine, but that process will have
the entire context of its parent, which is the browser itself.  Given
how much memory browsers use these days, this seems awfully wasteful.

A second problem is that all data will have to pass between the browser
process and the xine process, which will mean lots of copies and
constant context switching, which may lead to poor performance.

Am I correct in the above observations?  If so, I see two ways around
these problems:
1. Run xine in the same process as the browser.  Since xine is
   multi-threaded, I'm not sure if this is even possible (or if it is,
   how it will interact with browser threads).  (I've never done
   any multi-threaded programming (except in java), so pardon my
   ignorance).
2. Run xine in a separate process which is vfork'd, and which execs a
   xine_plugin executable.  The browser plugin would communicate with
   the xine_plugin process using RPC calls.  In order to limit this
   communication to control information only (e.g., window changes),
   the xine_plugin process would have to do its own data streaming.
   This is desirable for two reasons: (a) http streaming support is
   already part of xine (although it doesn't seem to be fully
   functional yet -- it crashed when I tried to use it), and (b) in the
   future, we might want to do streaming other that http streaming,
   for example we might want to implement MMS streaming.

I am leaning towards the second option.  In fact, I believe it may be
advantageous to create a browser plugin which is more general and
applies not just to xine, but to all kinds of applications (along the
lines of plugger.so).  The main difference from plugger is that it would
have interactions with the application process even after it has been
launched, and it wouldn't deal with any browser-based streaming, or rely
on data being stored in a local file, instead assuming that the
application will deal with its own streaming.  It might perhaps even be
possible to extend plugger to achieve this.

I am envisioning that the plugin application to be launched will be
determined by lookup in a mailcap file, and that application (e.g.,
xine_plugin) will be launched in a separate process, with all the
arguments to NPP_New() passed in as parameters (e.g., the SRC, Width,
Height, etc. obtained from the EMBED tag on the web page).  In this
case, the plugin application will treat the value of the SRC tag as the
URL it should stream from, and open a direct connection to the
corresponding host.

We also define an RPC API to inform the plugin application process
whenever the window within the browser changes (the plugin's
NPP_SetWindow() function gets called when this happens), or when the
browser calls NPP_Destroy().  What kind of RPC API would make sense
here?  CORBA?

I'd be willing to define the API and write such a generic netscape
plugin if folks feel this is the right approach.

regards,
-Zubin