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

["Malcolm Lansell" <mlansell@xxxxxxxxxxxxxx>]

It's interesting that you should mention this right now!  I've been a bit
quiet lately, but now you've forced my hand ;-) ...

I've decided to abandon the MVP - I'm fed up converting movies to mpg
(which
takes my PC around 7 hours), and would also like to retain the multichannel
audio.  I had installed Linux with the idea of rewriting the native MVP
code, but to be honest, I hate working with Linux - it's like stepping 10
years back in time, and you'd have to be blinded by a hatred of all things
Microsoft to insist it was better than Windows.  But I digress.  By the
time
I'd have got everything hooked up and working, the MVP would probably be
obsolete anyway.  I banished Linux and have been looking for an alternative
media player.

I've come to the conclusion that there is still no off-the-shelf box
available that can do what I want - ie stream audio, pictures and DVD files
(with menus).  I've decided that a PC based solution is best for me
(quiet/fanless small form factor boards are becoming ever more powerful).

So, this past month I've been rewriting the xPL C++ lib (better structure,
and documentation!) and I've also been working on an xPL connector for
VideoLan (www.videolan.org), a handy piece of software that can stream DVD
ISO files over the network (if mounted using Daemon tools, or Nero
ImageDrive - which was to be done automatically as part of the connector).
The idea is that this connector just responds to xPL commands as if they
were a remote control - Play, Stop, Pause, Chapter select etc.  It wouldn't
attempt to do anything like playlists, database scanning etc - it would
merely play the file as requested and then stop until another command came
along.

I wasn't planning any kind of rival to xPLRioNet - I just needed support
for
this particular application - but designing this app did make me wonder
whether xPLRioNet was trying to do too much within one application, and it
seems that you are thinking along the same lines.  At the very least, a
modular approach will allow others to share the programming burden.

I too was about to suggest a replacement for audio.basic - my app currently
uses something called av.basic, to cover video related controls, but it
sounds like the same thing that media.basic would be (and media.basic is
probably a better name anyway).  Perhaps we should come up with a list of
all the commands we will need?

As for your plans for xplMediaNet - I'm fine with the idea of a core module
handling streams of data for those applications that need it, but I think
all control and status communication between modules should be handled
through xPL messages, rather than some xPLMediaNet specific channel - after
all, that's what it's there for, and would allow maximum flexibility.  For
example, VideoLan doesn't require a data-serving application (it can stream
from a network share), and therefore wouldn't need to use the core module.
It would be nice however, if it could still be controlled via xPL in the
same way as the other modules.

Mal






----- Original Message -----
From: "Tony Tofts" <tony@xxxxxxx>
To: <ukha_xpl@xxxxxxx>
Sent: Monday, March 07, 2005 7:54 AM
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
> Yahoo! Groups Links
>
>
>
>
>
>
>



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