WebAPI/Inter App Communication - Revision history

Chaasof at 23:53, 1 October 2014

2014-10-01T23:53:21Z

← Older revision		Revision as of 23:53, 1 October 2014
Line 99:		Line 99:

	Google Message Passing: https://developer.chrome.com/extensions/messaging.html		Google Message Passing: https://developer.chrome.com/extensions/messaging.html

			[[Category:Web APIs]]

Mcaceres: s/Future/Promise

2014-04-15T15:41:51Z

s/Future/Promise

← Older revision		Revision as of 15:41, 15 April 2014
Line 24:		Line 24:
	// The returned Future will contain an array of MessagePort, each of		// The returned Future will contain an array of MessagePort, each of
	// them representing an peer that allowed the connection.		// them representing an peer that allowed the connection.
	~~Future~~ connect(DOMString keyword);		Promise connect(DOMString keyword);

	// The returned Future will contain ''true'' if at least a peer has been		// The returned Future will contain ''true'' if at least a peer has been
	// selected, ''false'' otherwise.		// selected, ''false'' otherwise.
	~~Future~~ registerConnections(DOMString keyword);		Promise registerConnections(DOMString keyword);

	void unregisterConnections(DOMString keyword);		void unregisterConnections(DOMString keyword);
Line 34:		Line 34:
	// The returned Future will contain ''true'' if at least a peer is allowed		// The returned Future will contain ''true'' if at least a peer is allowed
	// to communicate with the application, ''false'' otherwise.		// to communicate with the application, ''false'' otherwise.
	~~Future~~ connectionsRegistered(DOMString keyword);		Promise connectionsRegistered(DOMString keyword);
	};		};

Airpingu: /* Description */

2013-09-04T15:37:31Z

Description

← Older revision		Revision as of 15:37, 4 September 2013
Line 1:		Line 1:
	= Description =		= Description =

	~~(note~~: this proposal has a newer version at [https://wiki.mozilla.org/WebAPI/Inter_App_Communication_Alt_proposal Inter App Communication API Alt Proposal] and is currenly under implementation at [https://bugzilla.mozilla.org/show_bug.cgi?id=876397 Bug 876397])		Note: this proposal has a newer version at [https://wiki.mozilla.org/WebAPI/Inter_App_Communication_Alt_proposal Inter App Communication API Alt Proposal] and is currenly under implementation at [https://bugzilla.mozilla.org/show_bug.cgi?id=876397 Bug 876397].

	An application wants to send or get information with another application. For example, some communications related applications (Skype, SMS, dialer) could send communication logs to a logging ''service'' that would then show the log of all communications to the user. Otherwise, an application might want to know which music is currently playing and get this information from a music player.		An application wants to send or get information with another application. For example, some communications related applications (Skype, SMS, dialer) could send communication logs to a logging ''service'' that would then show the log of all communications to the user. Otherwise, an application might want to know which music is currently playing and get this information from a music player.

Airpingu: /* Description */

2013-09-04T15:37:07Z

Description

← Older revision		Revision as of 15:37, 4 September 2013
Line 1:		Line 1:
	= Description =		= Description =

			(note: this proposal has a newer version at [https://wiki.mozilla.org/WebAPI/Inter_App_Communication_Alt_proposal Inter App Communication API Alt Proposal] and is currenly under implementation at [https://bugzilla.mozilla.org/show_bug.cgi?id=876397 Bug 876397])

	An application wants to send or get information with another application. For example, some communications related applications (Skype, SMS, dialer) could send communication logs to a logging ''service'' that would then show the log of all communications to the user. Otherwise, an application might want to know which music is currently playing and get this information from a music player.		An application wants to send or get information with another application. For example, some communications related applications (Skype, SMS, dialer) could send communication logs to a logging ''service'' that would then show the log of all communications to the user. Otherwise, an application might want to know which music is currently playing and get this information from a music player.
Line 6:		Line 8:

	This API is only there to create a bridge between two applications. The only intended UI is for security reasons, to select communication peers.		This API is only there to create a bridge between two applications. The only intended UI is for security reasons, to select communication peers.

	~~[https://bugzilla.mozilla.org/show_bug.cgi?id=876397 Bug 876397] is fired for the implementation.~~

	= TODO =		= TODO =

Airpingu: /* Description */

2013-07-01T09:16:54Z

Description

← Older revision		Revision as of 09:16, 1 July 2013
Line 7:		Line 7:
	This API is only there to create a bridge between two applications. The only intended UI is for security reasons, to select communication peers.		This API is only there to create a bridge between two applications. The only intended UI is for security reasons, to select communication peers.

	A [https://bugzilla.mozilla.org/show_bug.cgi?id=876397 ~~bug~~] is fired for the implementation.		[https://bugzilla.mozilla.org/show_bug.cgi?id=876397 Bug 876397] is fired for the implementation.

	= TODO =		= TODO =

Airpingu: /* Description */

2013-07-01T09:16:31Z

Description

← Older revision		Revision as of 09:16, 1 July 2013
Line 6:		Line 6:

	This API is only there to create a bridge between two applications. The only intended UI is for security reasons, to select communication peers.		This API is only there to create a bridge between two applications. The only intended UI is for security reasons, to select communication peers.

			A [https://bugzilla.mozilla.org/show_bug.cgi?id=876397 bug] is fired for the implementation.

	= TODO =		= TODO =

Caspy7: Fixed spelling errors

2013-04-11T12:04:32Z

Fixed spelling errors

← Older revision		Revision as of 12:04, 11 April 2013
Line 3:		Line 3:
	An application wants to send or get information with another application. For example, some communications related applications (Skype, SMS, dialer) could send communication logs to a logging ''service'' that would then show the log of all communications to the user. Otherwise, an application might want to know which music is currently playing and get this information from a music player.		An application wants to send or get information with another application. For example, some communications related applications (Skype, SMS, dialer) could send communication logs to a logging ''service'' that would then show the log of all communications to the user. Otherwise, an application might want to know which music is currently playing and get this information from a music player.

	As for Web Activities, the idea is that an application will interact with another application. They will be put in relation ~~trough~~ a keyword. Regarding semantic, the main difference with Web ~~Activitiy~~ is that the interaction is not about delegating an action but about communicating. There is no caller/handler relationship. The relationship is actually 1:n while Web Activity is limited to a 1:1 relationship. Regarding user interaction, the main difference with Web Activity is that the other application will not be shown to perform a task, the entire process will happen in the background.		As for Web Activities, the idea is that an application will interact with another application. They will be put in relation through a keyword. Regarding semantic, the main difference with Web Activity is that the interaction is not about delegating an action but about communicating. There is no caller/handler relationship. The relationship is actually 1:n while Web Activity is limited to a 1:1 relationship. Regarding user interaction, the main difference with Web Activity is that the other application will not be shown to perform a task, the entire process will happen in the background.

	This API is only there to create a bridge between two applications. The only intended UI is for security reasons, to select communication peers.		This API is only there to create a bridge between two applications. The only intended UI is for security reasons, to select communication peers.
Line 77:		Line 77:
	== Accept a connection request ==		== Accept a connection request ==

	Only applications that have been previously selected by the user (when ''registerConnections'' is called) will get a connection request. Those applications will still be able to reject or accept the connection request. Accepting the connection has to be done ~~explicitely~~ by the receiver by calling ''accept()'' on the received object. Not calling ''accept()'' will ~~implicitely~~ reject the connection request.		Only applications that have been previously selected by the user (when ''registerConnections'' is called) will get a connection request. Those applications will still be able to reject or accept the connection request. Accepting the connection has to be done explicitly by the receiver by calling ''accept()'' on the received object. Not calling ''accept()'' will implicitly reject the connection request.
	var port = null;		var port = null;
	navigator.setMessageHandler('connect', function(request) {		navigator.setMessageHandler('connect', function(request) {

Mounir.lamouri: add 'similar work' section

2013-03-15T05:09:27Z

add 'similar work' section

← Older revision		Revision as of 05:09, 15 March 2013
Line 93:		Line 93:

	port.close();		port.close();

			= Similar work =

			Google Message Passing: https://developer.chrome.com/extensions/messaging.html

Mounir.lamouri: start

2013-03-15T02:01:39Z

start

New page

= Description =

An application wants to send or get information with another application. For example, some communications related applications (Skype, SMS, dialer) could send communication logs to a logging ''service'' that would then show the log of all communications to the user. Otherwise, an application might want to know which music is currently playing and get this information from a music player.

As for Web Activities, the idea is that an application will interact with another application. They will be put in relation trough a keyword. Regarding semantic, the main difference with Web Activitiy is that the interaction is not about delegating an action but about communicating. There is no caller/handler relationship. The relationship is actually 1:n while Web Activity is limited to a 1:1 relationship. Regarding user interaction, the main difference with Web Activity is that the other application will not be shown to perform a task, the entire process will happen in the background.

This API is only there to create a bridge between two applications. The only intended UI is for security reasons, to select communication peers.

= TODO =

* Use system messages for port messaging?
* Do we really need Future for all the methods?
* Should we use a Connection object that contains a MessagePort and an origin so both sides can filter with origin?
* Dynamic registration?
* Should we fire an event on the other port when a port call .close()?

= API =

== Caller ==

partial interface Application {
// The returned Future will contain an array of MessagePort, each of
// them representing an peer that allowed the connection.
Future connect(DOMString keyword);

// The returned Future will contain ''true'' if at least a peer has been
// selected, ''false'' otherwise.
Future registerConnections(DOMString keyword);

void unregisterConnections(DOMString keyword);

// The returned Future will contain ''true'' if at least a peer is allowed
// to communicate with the application, ''false'' otherwise.
Future connectionsRegistered(DOMString keyword);
};

== Receiver ==

=== Registration ===

An entry should be used in the manifest file to register as able to connect with another app requesting it. This entry should be named ''connect'' and each keywords should be used in an array:

{
'name': 'Foobar application',
/* ... */
'connect': [ 'keyword1', 'keyword2' ]
}

=== Connection acknowledgement ===

System messages named 'connect' fired when a connection request is received. The system message contains a ''ConnectionRequest'' object as a ''message''.

Dictionary ConnectionRequest {
MessagePort accept();
DOMString keyword;
DOMString origin;
};

= Usage =

== Setup a connection ==

First, the caller needs to ask the user to select peers he/she wants the app to communicate with. The list of applications being shown depends on the applications that advertises themselves as able to 'connect' with the given keyword:
registerConnections('foobar').then(function(result) {
result ? alert ('peer(s) selected') : alert('no peer selected');
});

Then, the ''connect'' method has to be called. The returned Future will contain an array of ''MessagePort''. Each of them will allow to communicate with a peer.
connect('foobar').then(function(ports) {
ports.forEach(function(port) {
port.onmessage = function(e) { alert(e.data); };
port.start();
port.postMessage({ msg: 'hi!'});
});
});

== Accept a connection request ==

Only applications that have been previously selected by the user (when ''registerConnections'' is called) will get a connection request. Those applications will still be able to reject or accept the connection request. Accepting the connection has to be done explicitely by the receiver by calling ''accept()'' on the received object. Not calling ''accept()'' will implicitely reject the connection request.
var port = null;
navigator.setMessageHandler('connect', function(request) {
if (request.origin != 'http://foobar.com') {
return;
}
port = request.accept();
port.onmessage = function(e) { alert(e.data); };
port.start();
});

== Disconnect ==

Calling ''close()'' on a port from either side will stop the connection.

port.close();