RE: xPL Readme.txt (more Questions!)

["Tony Tofts" <tony@xxxxxxxxxx>]

> Perhaps I'm getting ahead of the game, but I was under the impression
> that the idea of new clients created by other authors was to be
> supported, in which case we would need some form of plug-in approach,
> rather than inclusion in the main build.

Misunderstanding here. Each client _is_ an independent module, there really
is no "main build" other than the core loader that does nothing
other than
load the modules and allow cross communication etc

When I say the server is the client, I mean nothing is currently processed
on the physical client "device", the client "module"
does all the processing
(basically the client module and device make up the whole device as far as
xplmedianet is concerned. A device module must offer certain functions but
how it processes or offloads this to the device is between the client
module
and the device)

> Yes, playing/next is what I was talking about. Those schemas relate to
> either a stream (which I assume means shoutcast
> etc) or an genre/artist/album setup.  I think the issues arise because
> you're concentrating on music, whereas my main interest is video.  If
> I have a command to play a video file, I don't have artist/album etc
> to report.  I think we need a schema that either reports the filename,
> or the entire
> path+filename, but I'm not sure which would be most
> appropriate for xPLMediaNet.  I know I could invent my own schemas,
> but for the sake of compatibility I'd like to use the xPLMediaNet ones
> as much as possible - that way we make life as easy as possible for
> the end user.

For xplmedianet the plan for videos was just to give the filename (no
extension)

> Playlists to me just mean a list of files.  If they happen to be music
> or video is neither here nor there - if a client can't play it then it
> should just skip.

In xplmedianet it supports m3u palylists, but the client device isn't
expected to know anything about it. The playlist source breaks it down into
a list of tracks for the device.

Playlists, for playlists read "current playlist", in xplmedianet
is the list
of tracks queued (this is held at the client module level)

i.e. you'll never see an xpl message from xplmedianet saying it's playing a
'playlist'

> I must be missing a step here.  As an example, suppose someone wanted
> to use the xPLMediaNet web interface to trigger the playing of an MP3
> file on Media Portal.
> Somewhere along the line, that command is going to come from
> xPLMediaNet as an xPL Message.

xPL is just an interface module like any other (in fact it's no different
to
the web interface)

Each client module has standard hooks that allow it to be told what to do,
and an interface has standard hooks that a client device can call for
outgoing information. In addition to standard hooks, the clients have a set
of standard settings that the interface can access.

So for xpl, a message comes in, it passes it to the client (in a standard
text format), the client actions it

When the client wants to send out status messages it creates them in a
standard format, tells the core it wants to send the message, the core then
passes the message to _all_ available interface modules that support
messages, and the xpl module then sends it out.


Regards
Tony