xPLRioNet is Dead?, Long live xPLMediaNet? - xPLRioNet users please read!

["Tony Tofts" <tony@xxxxxxxxxx>]

Hi all,

Been thinking about the long term future of xPLRioNet and I'm not sure it
has one.

Below is my thinking for a long term replacement, though initially based on
the existing code of xPLRioNet to speed development (and avoid re-inventing
the wheel).

I'd really like your thoughts and comments please?

The idea behind xPLMediaNet is exactly the same as xplrionet, i.e. to
provide a single integrated media server for xPL

The main difference is that it will take a modular approach with a core xPL
service and then add-on dll's to handle specific shared functions and
specific devices

My current thinking is:

A) Core module, this is the service and is responsible for ALL network
traffic that isn't device specific (e.g. xPL, NFS, tftpd etc etc). It will
also handle the flow of shared information between modules and handle the
shared ports. It's also responsible for loading the other required modules.

B) Source modules (e.g. Database, media scanner, shoutcast streams, tivo)

C) Interface modules (e.g. web interface)

D) Utility modules (e.g. mediacast aka riocast, dhcp, transcoding)

E) Device modules (e.g. rio, exstreamer, slimp3, mvp, winamp etc) These
must
also provide there own services (like NFS) but hook thru the core module
shared ports.

Where a shared service can be provided by a utility module (say TFTPD) then
this will be provided as a utility module, but this module will hook thru
the core module (just like a device module tftpt implementation must) so
that where necessary device specific tftpd implementations can also be made
without port clashing.

This approach means if you don't like something you can roll your own, if
you have a device others don't have you can write your own (using an
existing module to speed development)

The idea of the core handling all non-device-specific network traffic is so
that where 2 or more modules/devices need to share a common service port
like NFS then the core module can police the port, passing traffic
to-and-thro as needed.

Obviously each module type will have pre-defined hooks to handle the way
certain functions are processed (like hooking into the NFS port).

Also it means only modules that are actually being used are loaded in
memory
(i.e. if you don't own an MVP then no mvp code is loaded). At least that's
the theory...

The device template will include compulsory code such as producing an xPL
displayable menu system (which must be implemented even if the device
doesn't have it's own display - like the exstreamer)

A single xml file will be used to hold the settings for all modules, and
this will (probably) be controlled exclusively by the core module.

All the modules above will initially be written based on the existing code
in xplrionet (with the necessary changes to fit into the new scheme)

I also think that xplrionet's current b@st@rdis@tion of the audio.basic
schema should be dropped in favour of a new media.basic schema?

If we go down this route then xplrionet development will cease (other than
any major bug fixes to the existing code base) and any support from me will
be limited to maximise the time available over the next couple of months
while the new version is coded.

Anyone have any thoughts/comments/suggestions please?

Regards
Tony



xPL Links: http://www.xplproject.org.uk http://www.xplhal.com http://www.xpl.myby.co.uk
To Post a Message: ukha_xpl@xxxxxxx
To Subscribe:  ukha_xpl-subscribe@xxxxxxx
To Unsubscribe:  ukha_xpl-unsubscribe@xxxxxxx