Navigation

Each media server plug-in runs in its’ own process, in a separate Python
instance. This ensures that plug-ins can’t interfere with each other, or with
the operation of the server. Plug-ins communicate with the media server over
sockets and act like mini HTTP servers, receiving standard HTTP requests and
responding with XML-formatted data. This process is completely transparent to
the plug-in developer - the framework will handle receiving requests, routing
them to the correct place within a plug-in, and sending a response back to the
server.

Plug-in’s don’t behave quite like normal Python programs. A plug-in isn’t
a program in its’ own right - the framework’s runtime environment is
the program, which dynamically loads the plug-in code as part of the
initialization routine. The runtime handles common tasks like run loop
management, request handling, logging and data storage, and calls specific
functions in the plug-in when necessary.

Because media server plug-ins are a little different to regular Python programs,
they can behave strangely in certain situations. There are a few
key areas where regular Python rules do not apply that you should be aware of.

Because plug-ins are executed within the framework’s runtime environment, the
code structure is more strict than in a normal Python program.
All of the plug-in’s code needs to be contained within functions. Although
it is generally safe to initialize simple variables with types like
str, int or bool outside a function,
anything more complicated (especially involving framework functions) may
produce unexpected results or fail completely. This is because the runtime
environment needs to be fully initialized before using any of the framework
methods, and code in plug-ins that exists outside a function is executed
as soon as the plug-in is loaded. Any code you want to execute when the
plug-in loads should be put inside the Start() function.
More information can be found in the functions section.

One of the biggest hurdles for existing Python developers to overcome is breaking old habits
when it comes to developing plug-ins. For instance, many developers may already
be familiar with using the urllib and urllib2 modules to make
HTTP requests, but all of the code required to perform a request can be replaced
by calling a single method in the HTTP API. This also has other
benefits, like automatic cookie handling and the option to cache the server’s
response.

While creating the framework APIs, a great deal of care was taken to make
plug-in development as easy as possible. If you take the time to familiarize
yourself with how the framework operates and the features it provides, you’ll
become much more productive when writing plug-ins.

Another side effect of the plug-in architecture is that plug-ins are incapable
of running by themselves. Because they rely heavily on the framework APIs
and the runtime environment, plug-ins must be started by the media server.