[JCasner]

Hey all,

I just put up a patch on behalf of the Zeppelin Project that adds a few commands to the HTTP interface for interacting with whatever Controls are present on the screen at the time. Link to the tracker is below, followed by the description, and of course suggestions or comments are welcome.

https://sourceforge.net/tracker/index.ph...tid=581840

This patch adds the following commands for use through the HTTP interface:
GetControls - returns a list of all the controls in the current window.
RemoveControl - With no parameters it removes the currently focused
control, given an id it will remove all controls of that id, and given an
id and a type it will remove all controls with both.
AddControl - given a type and all the relevant parameters, will add the
appropriate control to the screen (for example:
http://xbox/xbmcCmds/xbmcHttp?command=Ad...ronman.png puts a picture of Iron
Mans face in the top left corner of the screen ).

Josh

[RobotTwo]

Just posting a thread from the tracker into the forums here on this topic...

Date: 2008-06-21 14:10
Sender: nobody
Logged In: NO

@nad, any feedback from you about this here?

@Joshua, again, maybe you should post in the forum about this idea for an
open dicusssion, (and/or maybe even PM nad for private dicussion about the
HTTP API, and/or D4rk and Topfs2 about the EventClient idea).


Date: 2008-06-19 21:47
Sender: nobody
Logged In: NO

Please see the SVN for both C++ and Python examples of EventClients:
http://xbmc.svn.sourceforge.net/viewvc/x...ntClients/

EventClient to EventServer is a 'push' system that I beleieve also support
the HTTP API commands (or maybe not yet but planned?)



Date: 2008-06-19 21:00
Sender: nobody
Logged In: NO

What about using an EventClient instead? After two-way communication
support has been implemented into XBMC's EventServer that is. The
EventServer is still is early development but Topfs2 and D4rk plan on
expanding its functionality.
http://wiki.xbmc.org/?title=EventServer

Also checkout EventGhost:
http://www.eventghost.org

PS! May I suggest that you post this in the development forum for
dicussion as a lot more people read that on a daily basis than this patch
tracker.


Date: 2008-06-19 20:33
Sender: robottwo
Logged In: YES
user_id=133227
Originator: NO

Stable is always a good thing

Essentially though, we want to make sure we can externally script XBMC
(for either an external process, or even better, from another host on the
network).

My understanding is that the Python scripting API only allows for scripts
kicked off internally from within XBMC. This doesn't allow it to respond to
external events (like signals from external apps).

In other words, we want to "push" to XBMC, not have it "pull."

Can this be done with the Python API?

Also, as a side note, what's the deal with Python stability? I've seen it
consistently crash XBMC when running the included samples...


Date: 2008-06-19 20:09
Sender: jmarshallnzAccepting Donations
Logged In: YES
user_id=851643
Originator: NO

If you want it stable, I suggest that doing it via the httpapi is not the
way to go. There
are threading issues that may abound, and certainly there are cases where
the webserver
effectively stops, killing off any access you may have.

Graphics locks and so on for a start certainly need to be taken (they may
already be, I am
not sure). Assuming that is done, I don't see much of a problem other
than the duplicate
code, and the other comments I made earlier. Python can handle this stuff
just fine (and
is much more flexible), so I will need some convincing before adding such
a feature to the
SVN. That doesn't mean you can't continue to use it with the patched
version ofcourse

Cheers,
Jonathan


Date: 2008-06-19 19:04
Sender: robottwo
Logged In: YES
user_id=133227
Originator: NO

Another reason to expose this functionality via the HTTP API is that this
allows external scripting of XBMC, versus only allowing that support via
the [currently unstable] Python API.



Date: 2008-06-19 18:51
Sender: robottwo
Logged In: YES
user_id=133227
Originator: NO

Hi jmarshallnz,

The ultimate goal is to build a compositing engine into XBMC. Some
examples of the things this patch (along with additional patches we are
developing) will allow in the future:

- CNBC-style display, where the screen is divided into segments, with
multiple independent content playing in each segment (video, RSS,
slideshows, etc).

- Placing a logo (or animated logo) transparently over playing
content, similar to how TV stations put their logo in the corner while
shows are playing

- Sports or NFL-style overlays, where a picture is shown in the
background, and animations, slideshows, or pictures are overlayed on top

- Lots of other possibilities....


Date: 2008-06-18 23:20
Sender: jmarshallnzAccepting Donations
Logged In: YES
user_id=851643
Originator: NO

I am personally against this. For a start one needs to check that it's
threadsafe. Is the graphicscontext locked before this is done?

Secondly the patch contains text encoding changes (see the degrees celcius
sign stuff).

Thirdly the changes to GUIWindow and GUIControlGroup are not good enough:
For a start the "typed" version of GetControl doesn't take the type down
into the controlgroup. Further, I see little point in duplicating the
entire routines, instead, surely one should call the other. Lastly
GetControlType() returns an enum, thus you should be passing one in.

In either case, I don't like where this patch is heading in particular.
If you want to be able to add controls, the better way to do it (IMO) is
via a pythonscript. Opening guilib up in this way is problematic.

Perhaps if you indicate exactly WHY said functionality is wanted, we can
explain the right way to go about things?


Date: 2008-06-17 17:25
Sender: gamester17SourceForge.net DonorProject AdminAccepting Donations
Logged In: YES
user_id=630186
Originator: NO

Thanks Joshua!

@nad, can you please review, comment, and/or commit this patch?
http://forum.xbmc.org/showthread.php?tid=34082

PS! Please don't forget the documentation for the wiki
http://wiki.xbmc.org/?title=XBMC_Online_Manual

[RobotTwo]

Some arguments for placing this functionality (with appropriate stability fixes ) in the http api:

• The HTTP API is a perfect, language agnostic and host agnostic interface for external scripting (why have an http api if not to use it for stuff like this?)
  
• The two listed "drawbacks" for the eventserver are specifically the things we're trying todo:
  

  * Currently EventServer cannot send any information back to the clients. This is something we plan to incorporate.
  * EventServer is not designed to be able to send built in commands like playurl "foo". This might change in the future.

Certainly, the fact that you are mentioning that the http server isn't always available is a concern I haven't seen the web server become unresponsive ... does anyone know how to reproduce the issue, or what causes it?


PS:

I would assume that good approach in the future would be to reimplement the HTTP API as a call-through to the eventserver, once those two drawbacks are resolved?

[malloc]

Couldn't you call a python script from the http interface?

[malloc]

As far as python stability goes, you're welcome to submit patches.

[RobotTwo]

Why introduce another level of abstraction from the HTTP API?

Conceptually, what's the advantage of calling python to call C++ instead of calling C++ directly?

[nad]

RobotTwo:

I love these ideas and is the main reason I created the httpapi however I can understand the caution shown by jmarshall.

It might not be elegant but would malloc's suggestion be workable?

If not, then would you consider moidfying your patch to alleviate jmarshall's coding concerns?

I too haven't found a problem with the webserver stability.

[RobotTwo]

RobotTwo:

I love these ideas and is the main reason I created the httpapi however I can understand the caution shown by jmarshall.

It might not be elegant but would malloc's suggestion be workable?

If not, then would you consider moidfying your patch to alleviate jmarshall's coding concerns?

I too haven't found a problem with the webserver stability.

I think what makes the most sense to to go ahead an implement this as functionality in the HTTP API. It's also a high priority for things to work

JMarshall,
Other than the comments you made earlier, do you have any other concerns? We'll re-work the patch based on your earlier input regarding code stability and method calls, and then resubmit.

[Gamester17]

Have you looked at extending the EventServer for two-way communication then make a EventClient for this instead? EventClient to EventServer is a 'push' system designed for XBMC, I believe the API also support the HTTP API commands (if not then it is planned I think?)
http://wiki.xbmc.org/?title=EventServer
http://xbmc.svn.sourceforge.net/viewvc/x...ntClients/



PS! Also checkout EventGhost if you like to make an EventClient for XBMC's EventServer:
http://www.eventghost.org

[RobotTwo]

Have you looked at extending the EventServer for two-way communication then make a EventClient for this instead? EventClient to EventServer is a 'push' system designed for XBMC, I believe the API also support the HTTP API commands (if not then it is planned I think?)
http://wiki.xbmc.org/?title=EventServer
http://xbmc.svn.sourceforge.net/view.../EventClients/



PS! Also checkout EventGhost if you like to make an EventClient for XBMC's EventServer:
http://www.eventghost.org

Yes. I like the idea of a universal standard like HTTP much better than a "proprietary" model like eventclient, especially since we are really planning to do remote scripting/management of XBMC possibly over WAN connections, and using HTTP as a transport means that everyone's existing firewalls/encryption/blahblahblah will Just Work.

Also, eventClient was really designed for "remote control" sort of usage, so it needs a lot of work to get to the point where it can do what the http api already does.

[jmarshall]

IMO a better solution for the skin stuff (eg adding images from http or whatever) is to do it from the skin. That way there's no need to expose any of the guilib to other bits of XBMC and it doesn't require the webserver to be running. I guess it depends on exactly what you are after though.

I don't really see the point in the GetControls() routine - what were you gunning for with that?

Cheers,
Jonathan

[RobotTwo]

Basically, by the time we're done, skins aren't really going to be "skins" anymore. Instead, they'll be a real-time modifiable compositing engine. What we don't have with the current skin system is the ability to change the skin layout in real time, without preconfiguring it (and to have it be done by a remote agent).

Along with another patch we are preparing which will allow for each element to have its own independent playlist, this makes XBMC insanely flexible, and allows it to function in roles other than (and in addition to) an HTPC.

For example, you would be able to use XBMC to run a TV station (think of how tv shows get shrunk up while the credits are showing, so they can show what's coming up next along the bottom or side, or how they superimpose a logo transparently over the playing video).

[RobotTwo]

Another way to put it: Right now, you are thinking of XBMC as the server and the remote thing as the client.

Reverse that: think of XBMC as the client, connecting to a server which tells it how to behave.

[JCasner]

I've updated the tracker on sourceforge with a version that accommodates hopefully all of jmarshallnz's suggestions, so if you have any other issues with it please let me know.

Josh