Difference: ApplicationsMessagingInitialQuestionsTen (1 vs. 4)

Revision 42012-06-26 - root

 
META TOPICPARENT name="ApplicationsMessagingInitialQuestions"


How do we balance the need for messages to be general enough for max interop, with the specificity needed to exploit the full power of an app?

Example 1. We might define a message that can load an image, but some applications are capable of loading several images at once.
_if an application is capable to loading several images at once, maybe it should define(standardize) a new message that exposes this functionality. Clisnts that wish to take advantage of this functionality will know about this message and can dynamically discover when an application that provides this message is available.

An alternate solution for this particular use-case is to define all messages to be list-based in some way - i.e. a list of values can be provided wherever a single value is expected - then applications can consume list-valued messages in their most efficient way. This doesn't solve the general use case of applications with additional functinaliy however. -- NoelWinstanley_


Messages might mean different things to different apps.

E.g. a 'loadImage' message might mean to render it for display to one app, plot its histogram to another, or stage it for processing to third. How do we deal with this in a user-friendly way?
_Maybe the dynamic discovery mechanism provides some ways to get human-readable hints about the different intentions of the messages that an application provides.

However, this doesn't solve the problem where a single application can both render an image and process it - here the application can interpret a single message in two different ways. A possible way to resolve this is that such an application registers different 'interfaces' separately (e.g. a display interface, processing interface) - and each can be messaged to directly. Maybe these interfaces are analogous to bluetooth or usb 'profiles' - of which there's a subset that are well known. The idea of profiles might fit with the 'client groups' mentioned elsewhere - so a message (e.g. loadVotable) could be broadcast to all connected apps which supported a particular profile (e.g. TableDisplayProfile).

-- NoelWinstanley_


Revision 32007-02-08 - NoelWinstanley

 
META TOPICPARENT name="ApplicationsMessagingInitialQuestions"

Deleted:
<
<
 
<--  
-->

How do we balance the need for messages to be general enough for max interop, with the specificity needed to exploit the full power of an app?

Example 1. We might define a message that can load an image, but some applications are capable of loading several images at once.
Added:
>
>

_if an application is capable to loading several images at once, maybe it should define(standardize) a new message that exposes this functionality. Clisnts that wish to take advantage of this functionality will know about this message and can dynamically discover when an application that provides this message is available.
 
Deleted:
<
<
_if an application is capable to loadin several images at once, maybe it should define(standardize) a new message that exposes this functionality. Clisnts that wish to take advantage of this functionality will know about this message and can dynamically discover when an application that provides this message is available.
 An alternate solution for this particular use-case is to define all messages to be list-based in some way - i.e. a list of values can be provided wherever a single value is expected - then applications can consume list-valued messages in their most efficient way. This doesn't solve the general use case of applications with additional functinaliy however. -- NoelWinstanley_

Messages might mean different things to different apps.

E.g. a 'loadImage' message might mean to render it for display to one app, plot its histogram to another, or stage it for processing to third. How do we deal with this in a user-friendly way?
Changed:
<
<
>
>

 _Maybe the dynamic discovery mechanism provides some ways to get human-readable hints about the different intentions of the messages that an application provides.

However, this doesn't solve the problem where a single application can both render an image and process it - here the application can interpret a single message in two different ways. A possible way to resolve this is that such an application registers different 'interfaces' separately (e.g. a display interface, processing interface) - and each can be messaged to directly. Maybe these interfaces are analogous to bluetooth or usb 'profiles' - of which there's a subset that are well known. The idea of profiles might fit with the 'client groups' mentioned elsewhere - so a message (e.g. loadVotable) could be broadcast to all connected apps which supported a particular profile (e.g. TableDisplayProfile).

-- NoelWinstanley_


Revision 22007-02-08 - NoelWinstanley

 
META TOPICPARENT name="ApplicationsMessagingInitialQuestions"

Deleted:
<
<
 
<--  
-->

How do we balance the need for messages to be general enough for max interop, with the specificity needed to exploit the full power of an app?

Example 1. We might define a message that can load an image, but some applications are capable of loading several images at once.
Added:
>
>
_if an application is capable to loadin several images at once, maybe it should define(standardize) a new message that exposes this functionality. Clisnts that wish to take advantage of this functionality will know about this message and can dynamically discover when an application that provides this message is available.

An alternate solution for this particular use-case is to define all messages to be list-based in some way - i.e. a list of values can be provided wherever a single value is expected - then applications can consume list-valued messages in their most efficient way. This doesn't solve the general use case of applications with additional functinaliy however. -- NoelWinstanley_

 

Messages might mean different things to different apps.

E.g. a 'loadImage' message might mean to render it for display to one app, plot its histogram to another, or stage it for processing to third. How do we deal with this in a user-friendly way?
Added:
>
>
_Maybe the dynamic discovery mechanism provides some ways to get human-readable hints about the different intentions of the messages that an application provides.

However, this doesn't solve the problem where a single application can both render an image and process it - here the application can interpret a single message in two different ways. A possible way to resolve this is that such an application registers different 'interfaces' separately (e.g. a display interface, processing interface) - and each can be messaged to directly. Maybe these interfaces are analogous to bluetooth or usb 'profiles' - of which there's a subset that are well known. The idea of profiles might fit with the 'client groups' mentioned elsewhere - so a message (e.g. loadVotable) could be broadcast to all connected apps which supported a particular profile (e.g. TableDisplayProfile).

-- NoelWinstanley_

 

Revision 12007-02-08 - JohnTaylor

 
META TOPICPARENT name="ApplicationsMessagingInitialQuestions"


<--  
-->

How do we balance the need for messages to be general enough for max interop, with the specificity needed to exploit the full power of an app?

Example 1. We might define a message that can load an image, but some applications are capable of loading several images at once.

Messages might mean different things to different apps.

E.g. a 'loadImage' message might mean to render it for display to one app, plot its histogram to another, or stage it for processing to third. How do we deal with this in a user-friendly way?
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback