Proxy Orbiter - Revision history

Uplink: /* Web mediated comms */ Mention Web Orbiter 2.0 in the web comms

2011-07-11T11:57:46Z

Web mediated comms: Mention Web Orbiter 2.0 in the web comms

←Older revision		Revision as of 11:57, 11 July 2011
Line 43:		Line 43:

	Both require the <i>device_id</i> parameter, which selects which Proxy_Orbiter they'll operate on. The <i>device_id</i> is the device number of the Generic Web Device parent, not the Generic Proxy Orbiter child.		Both require the <i>device_id</i> parameter, which selects which Proxy_Orbiter they'll operate on. The <i>device_id</i> is the device number of the Generic Web Device parent, not the Generic Proxy Orbiter child.

			These pages are the same ones used by [[Web Orbiter 2.0]].

	===weborbiter_command.php===		===weborbiter_command.php===

Uplink: Add web protocol

2011-07-11T11:53:14Z

Add web protocol

←Older revision		Revision as of 11:53, 11 July 2011
Line 33:		Line 33:

	All commands must be followed by the \n (LF) character (UNIX style EOL). DOS style EOL (\r\n) won't work. All text parts of the replies (including the first line) are followed by LF.		All commands must be followed by the \n (LF) character (UNIX style EOL). DOS style EOL (\r\n) won't work. All text parts of the replies (including the first line) are followed by LF.

			==Web mediated comms==
			You don't have to connect to the Proxy_Orbiter directly. Actually, it's recommended you don't use the direct socket connection unless you can't use HTTP to access the Proxy_Orbiter through the Web Orbiter backend code.

			There are two pages of interest:

			* weborbiter_command.php
			* weborbiter_image.php

			Both require the <i>device_id</i> parameter, which selects which Proxy_Orbiter they'll operate on. The <i>device_id</i> is the device number of the Generic Web Device parent, not the Generic Proxy Orbiter child.

			===weborbiter_command.php===
			{\|
			\|-
			Syntax: /lmce-admin/weborbiter_command.php?device_id=<i>device_id</i>&cmd=<i>proxy_orbiter_command_string</i>
			\|}

			Sends the <i>proxy_orbiter_command_string</i> to the Proxy_Orbiter identified by <i>device_id</i> and returns the reply. The <i>proxy_orbiter_command_string</i> must be a URLencoded version of a complete socket command from the table above.

			This page won't run the IMAGE command intentionally. Use weborbiter_image.php for images.

			===weborbiter_image.php===
			{\|
			\|-
			\|Syntax 1: /lmce-admin/weborbiter_image.php?device_id=<i>device_id</i>
			\|-
			\|Syntax 2: /lmce-admin/weborbiter_image.php?device_id=<i>device_id</i>&file=<i>file_path</i>
			\|}

			Without the <u>file</u> parameter, weborbiter_image.php sends IMAGE to the Proxy_Orbiter and returns the main screen image.

			With the <u>file</u> parameter, weborbiter_image.php attempts to return the requested file from the filesystem. This form is used to retrieve cover art for the datagrids. Only files in /usr/pluto/orbiter and /home/mediapics will be served.

Uplink: /* Commands */

2011-07-11T11:31:41Z

Commands

←Older revision		Revision as of 11:31, 11 July 2011
Line 30:		Line 30:
	\|}		\|}

	In case of ERROR, the <b>ERROR\n</b> message is returned instead of the reply described above for any command.		In case of ERROR, the <b>ERROR</b> message is returned instead of the reply described above for any command.

	All commands must be followed by the \n (LF) character (UNIX style EOL). DOS style EOL (\r\n) won't work. All text parts of the replies (including the first line) are followed by LF.		All commands must be followed by the \n (LF) character (UNIX style EOL). DOS style EOL (\r\n) won't work. All text parts of the replies (including the first line) are followed by LF.

Uplink: Proxy_Orbiter protocol

2011-07-11T11:31:18Z

Proxy_Orbiter protocol

←Older revision		Revision as of 11:31, 11 July 2011
Line 1:		Line 1:
	[[Category: Orbiters]]		[[Category: Orbiters]]

			==Description==
	Proxy_Orbiter is built from the 'guts' of the full [[Orbiter]] you see on MD's but in this case it's a UI'less piece of software that runs on the Core and its job is to render the UI for the [[Touch Orbiter]] that is running remotely on the target device. Each Touch Orbiter has an associated instance of Proxy_Orbiter and the two work in partnership. Proxy_Orbiters do all the 'heavy lifting' of rendering the UI and interacting with the rest of the underlying system and this allows the remote device that is running the Touch Orbiter to be a much less powerful and very simple device indeed if needed.		Proxy_Orbiter is built from the 'guts' of the full [[Orbiter]] you see on MD's but in this case it's a UI'less piece of software that runs on the Core and its job is to render the UI for the [[Touch Orbiter]] that is running remotely on the target device. Each Touch Orbiter has an associated instance of Proxy_Orbiter and the two work in partnership. Proxy_Orbiters do all the 'heavy lifting' of rendering the UI and interacting with the rest of the underlying system and this allows the remote device that is running the Touch Orbiter to be a much less powerful and very simple device indeed if needed.

			==Commands==
			The following commands are for direct socket communication to the Proxy_Orbiter.

			All command replies start with a reply message followed by \n followed by an optional body of data.
			{\|border="1" cellspacing="0"
			!Syntax
			!Reply on success
			!Description
			\|-
			\|IMAGE\|\|IMAGE <i><size></i><br/><i><image data></i>\|\|Ask the Proxy_Orbiter to give us the image of the current screen. <i>size</i> is the size of the <i>image data</i> in bytes. <i>image data</i> is the actual unaltered image data, in binary form. There's no indication of the image format (which can be PNG or JPEG) and this must be inferred by other means.
			\|-
			\|XML\|\|XML <i><size></i><br/><i><xml_data></i>\|\|Retrieve the XML data for the Cisco 7970.
			\|-
			\|PLUTO_KEY <i><Key_ID></i>\|\|OK\|\|Used by the Web Orbiter and Cisco 7970 Orbiter in association with programmable soft keys.
			\|-
			\|TOUCH <i><X></i>x<i><Y></i>\|\|OK\|\|Notify the Proxy_Orbiter about a touch. X and Y are the coordinates of the touch. There's a literal <i>x</i> between X and Y.
			\|-
			\|ANYNEWS?\|\|NEWS <i><size></i><br/><i><answer></i>\|\|Ask the Proxy_Orbiter if there are any updates. The <i>answer</i> is either <i>yes</i> or <i>no</i>. Data size includes the LF line separator that follows the answer. If the <i>answer</i> is <u>yes</u>, the Touch Orbiter should refresh its screen as its own copy is out of date. The Touch Orbiter/Web Orbiter calls ANYNEWS? periodically (typically once every second).
			\|-
			\|SCREEN_XML\|\|SCREEN_XML <i><size></i><br/><i><xml_data></i>\|\|Request the current screen structure in XML format.
			\|-
			\|DATAGRID_XML <i><GridID></i>\|\|DATAGRID_XML <i><size></i><br/><i><xml_data></i>\|\|Request the data for Datagrid <i>GridID</i>. This command should be used only for grid objects described in the data returned by SCREEN_XML, as otherwise it's very likely the grid data is invalid and you'll receive and ERROR message.
			\|-
			\|DATAGRID_TOUCH <i><GridID></i> <i><Row></i> <i><Column></i>\|\|OK\|\|Similar to TOUCH, but for datagrids. Touch Orbiter/Web Orbiter sends this message when a datagrid cell in the [[Enhanced UI]] is activated.
			\|}

			In case of ERROR, the <b>ERROR\n</b> message is returned instead of the reply described above for any command.

			All commands must be followed by the \n (LF) character (UNIX style EOL). DOS style EOL (\r\n) won't work. All text parts of the replies (including the first line) are followed by LF.

Uplink at 10:13, 11 July 2011

2011-07-11T10:13:34Z

←Older revision		Revision as of 10:13, 11 July 2011
Line 1:		Line 1:
			[[Category: Orbiters]]

	Proxy_Orbiter is built from the 'guts' of the full [[Orbiter]] you see on MD's but in this case it's a UI'less piece of software that runs on the Core and its job is to render the UI for the [[Touch Orbiter]] that is running remotely on the target device. Each Touch Orbiter has an associated instance of Proxy_Orbiter and the two work in partnership. Proxy_Orbiters do all the 'heavy lifting' of rendering the UI and interacting with the rest of the underlying system and this allows the remote device that is running the Touch Orbiter to be a much less powerful and very simple device indeed if needed.		Proxy_Orbiter is built from the 'guts' of the full [[Orbiter]] you see on MD's but in this case it's a UI'less piece of software that runs on the Core and its job is to render the UI for the [[Touch Orbiter]] that is running remotely on the target device. Each Touch Orbiter has an associated instance of Proxy_Orbiter and the two work in partnership. Proxy_Orbiters do all the 'heavy lifting' of rendering the UI and interacting with the rest of the underlying system and this allows the remote device that is running the Touch Orbiter to be a much less powerful and very simple device indeed if needed.

Uplink: Add Proxy_Orbiter description that was originally in Touch Orbiter - for the CUWIN3500 in-wall Touch Panel

2011-07-11T10:12:38Z

Add Proxy_Orbiter description that was originally in Touch Orbiter - for the CUWIN3500 in-wall Touch Panel

New page

Proxy_Orbiter is built from the 'guts' of the full [[Orbiter]] you see on MD's but in this case it's a UI'less piece of software that runs on the Core and its job is to render the UI for the [[Touch Orbiter]] that is running remotely on the target device. Each Touch Orbiter has an associated instance of Proxy_Orbiter and the two work in partnership. Proxy_Orbiters do all the 'heavy lifting' of rendering the UI and interacting with the rest of the underlying system and this allows the remote device that is running the Touch Orbiter to be a much less powerful and very simple device indeed if needed.