The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024

Latest message you have seen: RE: xPLMediaNet Music Menu Layout


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

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


  • Subject: RE: xPLRioNet is Dead?, Long live xPLMediaNet? - xPLRioNet users please read!
  • From: "Neil Frost" <neil@xxxxxxxxxxxxx>
  • Date: Mon, 7 Mar 2005 09:06:35 -0000


Hi Tony,

Personally I think it's a good idea, along with the name change ;)

I'm just a user of xPLRioNet and it has answered all my hopes for an media
server application for my specific device and continues to add
functionality that I hadn't thought of and am taking advantage of.

I also assume that with a core module, development of new features and
devices would be easier to write and implement?

Keep up the good work Tony...

Cheers

Neil

________________________________

From: Tony Tofts [mailto:tony@xxxxxxx]
Sent: Mon 07/03/2005 07:54
To: ukha_xpl@xxxxxxx
Subject: [ukha_xpl] xPLRioNet is Dead?, Long live xPLMediaNet? - xPLRioNet
users please read!




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

xPL Main Index | xPL Thread Index | xPL Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.