An idea about interoperability and scripting...

[Clodo]

The idea is allow both the MP core and plugins sendind and receiving generic string command, simply by adding a
virtual method to IPlugin interface, to allow plugins receiving command, like

virtual IPlugin::onConsole(CommandInfo i)

(CommandInfo is an helper that contains a string command, and offer methods for parsing/extract info)

and adding a method to send command, like

void IPlugin::Send(CommandInfo i)

This allow:

- To write plugins that interacts with other plugins,
for example people can write a simple process plugin "MyTalk" that process command like "Speak 'Bye Bye!'", so other plugins
can send this type of command, without need to know if "MyTalk" is installed or not, and can be exists many plugins that do the same
things, allow users to choose the best for us...

- To write a plugins called "MyConsole" that allow advanced command at runtime, not possible via gui, like the console in many FPS games

- To write a plugins called "MyRemoteConsole", that create a socket in listening on a port, and receive/send command to connected client,
for example to allow interaction between many MP on lan, or a useful front-end for external display or peripherical connected via lan,
and people can write application that talk with MP without need to write a specific plugin for MP.
For example, we can write a plugin for Girder that, in response of an event, send a command to MP, or viceversa
when receive an event from MP that match, launch an action in Girder.
Potentially, is possible to use the Girder scripting language, lua, for control MP.

Second step, allow the users to write a script, without re-compile the source, for advanced and very custom MP personalization, for example:

function onConsole(CommandInfo i)
{
	if (i.sender=="Core") && (i.command=="Starting")
	{
		Send("Core","GoTo MyTv");
		Send("MyTV","SwitchChannel /Name:MTV");

		// To do that, the core need to implement a call like
		// Send("All","Starting") when the initialization is ended and the home menu is on screen...
	}

	if (i.sender=="MyVideo") && (i.command=="SchedulerRecordingEnded")
	{
		// a user-custom notifications
		Send("MyOSD","Show /Message:End recording of "+i.command.param["Title"]);

		// To do that, MyVideo need to implement a call like
		// Send("All","SchedulerRecordingEnded /Title:ABC")
		// and exists a plugins called "MyOSD" that process this type of command.
	}

	if (i.sender=="MyAlarm") && (i.command=="Alarm")
	{
		if (Receive("MyVideo","Status")=="Playing")
		{
			Send("MyVideo","Play /File:Alarm.avi /PipMode");   // Only when PipMode can be avaible!!
		}
		else
		{
			Send("MyOSD","Show /Message:Alarm!");
		}
	}	
}

( To allow scripting in MP (i don't understand if there is already a work about it), i think that this article
can be interesting:
http://www.codeproject.com/csharp/cs-script_for_CP.asp
,the idea is writing a C# script like the above, and MP directly compile it (like a process plugin) in a temp assembly and run)


For limit the cpu use,
- Send must accept a parameters that indicate the components/plugin that can receive the command, like the sample above,
or
- Every plugins or script can receive the command only after a "subscribe" command versus other plugins/script, like the open-source project EIBControl
(http://eibcontrol.sourceforge.net/).
This project is the origin of my idea, because i have an EIB installation in my house, and i want that MP interact with my house, for example
showing an osd message on all my MP when the doorbell is pressed...

Also, a dump of the console output can be useful to check the sequence of actions that cause a problem.

All the actual Action.ActionType command can be send with a Send("ACTION_VOLUME_MUTE"), received by the core.


I think it's not a difficult implementation, but need to be done in core MP, and also many plugins developer must support this architecture,
so what we think about this???

Thanks!

[Niall]

Clodo,

Theres some good ideas there.

The scripted plugins are definitely doable (from a coding pov) - and I have recently done a project where we sent uncompiled vb.net/c# source to a web service - where it was then dynamically run/and results returned. Via the uncompiled Script - you can perform pretty much any sort of functionality you want as well (that you could normally code in a compiled exe).

There are only a few lines of code required (Similar to plugin use but a couple more steps for dynamic compilation) - however takes a little bit of legwork if you are interfacing with other dll's (or classes outside the main system namespace). The cpu load is negligable as well and speed is not really reduced once internal methods are being used (as its compiled into a temporary assembly before execution - however you need late binding from your hosting application).

In terms of the communication - I've put forward a specification for PVR/Plugin/Component communication called PVRX - which I think covers a few of the ideas you raised below. It could probably work over EIB as well (instead of the XML Web Service) - and actually defines the format of the internal messages for PVR related functionality. Please see the PVRX post in this forum - or visit www.pvrx.org for some more information.

rgds

Niall

[Clodo]

Actually it's possible to write a plugins that send action, message, or keystroke to MP, so it's possible to
write a plugins that send command to MP, and it's possible to handle many event (for example, OnPropertyChange on GuiProperty), but this
require that every assembly must be the correct build, and if i write a plugin "alfa" that interact with a plugin "beta", i need the
assembly of "beta".

I think that a technique for interoperability between plugins and core:
- must be a "standard design guidelines" for core and plugins developers, so accepted by all developers
- must be implemented in MP core, cannot be implemented as process plugin, because also core need to support them
- must be assembly build indipendent

i think it's a very important also for building a scripting engine inside MP.

What type of technique (my proposal, PVRX or other) it's a detail, because if a techique exists in core, a plugins (like your PVRX) can
wrapper that, but actually for example it's practically impossible to intercept when the Alarm event in MyAlarm occur without changing the code,
because MyAlarm plugins doesn't expose any event.
Please note, it's not a critic to MyAlarm developer, it's only an example!

So, what others developers and lead developers think about this topic?

Ok, for now stability is more important of this, but we can start to study the best solution for interoperability of MP 9.9....

bye!

[tomtom21000]

Don´t know how close you looked at the source code and I have absolutely no knowledge about these things, apart from both having "script" in the title

Just in case, that this could be a starting point: But I am pretty sure you allready have seen this script thing:
http://nolanparty.com/mediaportal.so...ghlight=script

Allthough I understand your talking on a more conceptional/design level?

tomtom

[Clodo]

I write a new plugins MyScript (internal name: MyScript2 to avoid conflict..., very very alpha build...).

Download here and extract in process plugin folder.


When MP start, MyScript enumerates all *.cs 'script' file found in <home>plugins\process\MyScript, and for each
script, compile it in dynamic assembly, add all assembly references that MyScript have, create an instance and run.

Press 'Ctrl+S' inside MP to rebuild all scripts with feedback.
All feedback are logged.

The only script sample is:

using System;
using MediaPortal.MyScript;
using MediaPortal.GUI.Library;
using MediaPortal.Dialogs;

class Sample1
{
	public void Main() 
	{
			Log.Write("A log message from script...");
			
			GUIWindowManager.OnNewAction += new OnActionHandler(GUIWindowManager_OnNewAction);			
  }
  
  private void GUIWindowManager_OnNewAction(Action action)
	{
			if (action.wID == Action.ActionType.ACTION_KEY_PRESSED)	
			{
				if(action.m_key.KeyChar == 26)
				{				
		  		GUIDialogOK dlgOk = (GUIDialogOK)GUIWindowManager.GetWindow((int)GUIWindow.Window.WINDOW_DIALOG_OK);
					dlgOk.SetHeading("MyScript2"); 
					dlgOk.SetLine(1,"A messagebox from script when press Ctrl+Z...");
					dlgOk.DoModal(GUIWindowManager.ActiveWindow);
				}
			}
	}
}

that show a message when user press Ctrl+Z.



Tomtom21000 : A more powerful version can be a better replacement of actual MyScript?

The problem is that only people that know the code can write a script, so why a developer need to use this script features if can
simply create a process plugin directly?

For me, all script file must be derived from a base class that contains simple and generic method (like the method described in first post),
that allow interaction with other components (core and other plugins) in a safe and more simply mode, and allow
creating a 'wizard/macro' frontend for creating very simple script...

Enjoy!


Added..
I post the plugin in a new thread in correct forum to preserve the discussion here about the "conceptional" design...

[Clodo]

I try to explain my project.


I'm trying to develop a home-automation solution.

I have four htpc with MP installed, and each htpc control differents aspect of
home automation.

There are many device in an house that can be connected and controlled by an htpc,
In my house for example:
- An EIB bus installation to control light, sensor and motor (via RS232),
- WS3600 meteo station (via RS232)
- Denon Amplifier (via RS232)
- NEC PlasmaSync (via RS232)
- etc...

I want to implement a totally integrated system, using MP as interface, to control
all my home-automation, but i want also to contribute to this wonderful project.

For example.... the Denon Amplifier, i don't want to write a window-plugin that show some
simple command, because the selection of the commands to show for me it's a personal stuffs,
i want to write a plugin for interoperability, that allow all method
and events supported by Denon, and leave the "connection" between the IDE and the plugin to
the users directly, for example with a script like
"When i press F9, send 'Switch audio source' on Denon".
But i want also a command like "When i activate the 'close house' via eib, send 'Power off' on Denon".
So i need also remoting access between my 4 htpc in the house.

A xml web services, the interoperability solution used by 'webinterface plugin',
for me it's not the correct technique: restricted var type, http layer useless etc..

The best solution can be a normal .NET class library with all Denon functions, with method and
also events, and allow people to write script to control it using MyScript plugin, but
it's required a little bit of c# knowledge (particularry about event's handler) to use it from a generic non-devs MP users, and
i need to use net remoting (like the 'external control plugin') that add complexity.

If i understand correctly, the PVRX have the same complexity; i look the API, it's sound like a PVR-specific solutions... right?

So, i post the idea (this topic thread) to create a custom 'console like' management of method and events,
so i can create a normal .NET class library with public method and events for advanced/developers need,
and a 'console' layer for people that don't know very well c# and want to use it 'out of the box',
with a simple script or macro-style wizards that generate the scripts...



... I have the same problem with the EIB instabus, NEC PlasmaSync,
WS3600 meteo station, irrigation system, sensors, and other PIC/PLC controlled also by RS232 etc..

For each stuffs there are many open-source project, but there isn't a common unique
interface for an interoperability between system.

A stupid example, if i want to close my windows and show a notification in MP when rains,
i need the same code layers that control the meteo station, the EIB bus, and MP in the HTPC.


For me, can be a wonderful unique feature if MP can interact with different home systems
like the AMX or Creston systems (home/building-automation solutions). But there are many home electronics
that can be connected and need specific class library, so the code techique must be appreciated by many
possibile developers of this community..

so ... is the right direction? exists other better solutions?



Thanks! Specially to people that read all this post!