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

["Malcolm Lansell" <mlansell@xxxxxxxxxxxxxx>]

----- Original Message -----
From: "Tony Tofts" <tony@xxxxxxx>
To: <ukha_xpl@xxxxxxx>
Sent: Monday, March 07, 2005 11:11 AM
Subject: RE: [ukha_xpl] xPLRioNet is Dead?, Long live xPLMediaNet? -
xPLRioNet users please read!


>
> Hi Mal,
>
>> 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?
>
> Yes, good idea. Most of the commands I need are the ones already in
> xplrionet, but they need expanding a bit.

For VideoLan DVD playback, I'd need

Play (playlist, filename, or URL)
Stop
Pause (Unpause by pressing pause again, or play?)
Seek (+/- in seconds)
Next/Prev/Select (playlist entry, DVD title or chapter - perhaps context
sensitive, rather than separate controls?)
Volume (up, down or set level for each channel)
Mute
Record (I think I'll need this soon - I want to record the Today show on
Radio 4 for the hour before I drive to work - currently I only get to hear
the last half hour!).

I'm not sure yet about exactly what info I can get back from VideoLan, but
there would also need to be some kind of status messages sent back to
xPL-world.

>
>> 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 -
>
> The stuff passing thru the core will mainly be:
>
> A) xpl (it will act mainly as an intelligent hub, diverting traffic
only
> to
> the destinations, thereby reducing the xpl load on the individual
modules)
>

That seems like a decent idea - but will traffic also be sent to the rest
of
the xPL network, or will messages stay internal to the hub and its clients?

> B) shared service port policing (e.g. modules wishing to use nfs/ftp
ports
> etc)
>
> C) database activity (as this is inappropriate for xpl, in my view)
>
> D) handling requests for resources like streams (so a stream can be
> shared)
>

All sounds good - it's just the control of/by external xPL apps that
concerned me.  So long as xPL commands from (for example), the MVP menus,
and player status messages make it out to the wider xPL world, (and
similarly, commands from xPLHal get acted upon), we would have all the
flexibility we could want.

snip

> I'm not intending to make xplmedianet a distributed system across
multiple
> pc's though, so in the case of videolan it would be xpl control only.
> Though
> videolan can supposedly (I say supposedly as I've had nothing but
grief
> with
> it) act as a source for the mvp, so a source module for it (and
videolan
> could be on another pc) would be good - acting pretty much like
shoutcast
> source module.
>

I have only used VideoLan as a client, not as a server, so I've not come
across those issues.
Running the xplMediaNet system on a single PC doesn't appear to present any
problems.  My VideoLan app is basically a client in the same way as an
Exstreamer or MVP would be anyway.

Mal





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