Difference: ApplicationsMessagingInitialQuestions (1 vs. 9)

Revision 92012-06-26 - root

 
META TOPICPARENT name="ApplicationsMessaging"

Applications Messaging - Initial Questions for the Community

To spark off the discussion of what we want from an Applications Messaging System, we've prepared some questions and topics for discussion. If you have opinions on these issues, then please add your views to the appropriate page. Following this we'll try to distill people's views into some sort of consensus (if possible!), considering what is achievable in the time we have.

Questions to kick off the IVOA Applications Messaging discussion

General Questions

Comment

There is a general acceptance that message infrastructure and messaging syntax&semantics should be treated separately:

Infrastructure

  • Which set of platforms/languages should be able to access the messaging system? Comment
  • Do we need....?
    • Security?
      • How much?
    • Encryption?
    • Guaranteed delivery?
    • Guaranteed ordering?
    • Queuing of messages?
    • Transactions?
Comment
  • Everything changes: how do we deal with versioning of the protocol? Comment
  • Should the system be dynamic (apps discover each other at runtime), or static (apps can be discovered even when not running?)
    • Is there/should there be a mechanism to start non-running apps?
Comment
  • How do applications discover each other's capabilities?
    • Dynamically?
    • Through the registry?
    • Statically for apps they already "know"
Comment

Messages

  • Who should define messages? Comment
  • What should be the format of a message? Comment
  • What are the message categories? Comment
  • 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? Comment
  • 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? Comment
  • Do we need to be concerned with obsolescence of messages? Comment
  • In a Hub-based architecture, should the hub have any concept of the meaning of messages? Comment

Data Transport

  • What data formats should we use?
  • Do we need to send a data subset (i.e. rows from a table or image ROI only)?
  • Do we need to share access to data (rather than passing references and each app making a copy)?
Comment

Intradesktop Messaging Questions

General

  • Is a hub-based architecture best or should it be peer to peer or something else?
  • Do we need to be able to partition apps within a hub into separate mutually inaccessible groups?
  • Do we want a request-reponse style messaging?
    • Asynchronous messaging?
    • Polling?
Comment

PLASTIC-specific Questions

The following questions are to gauge how suitable PLASTIC is as a foundation for the restricted case of intradesktop application messaging:

Compatibility

  • Can your application send and receive messages via PLASTIC?
    • If not, why not?
  • Could you embed a PLASTIC Hub in your application?
    • If not, what's stopping you?

Ease of use

  • Should PLASTIC have more underlying transport protocols?
  • Should PLASTIC have fewer underlying transport protocols?
  • What would you change in the PLASTIC API?
  • How do we deal with a multi Hub world?
    • Do we need a protocol for "handover" as one hub shuts down?

Power

  • Is the PLASTIC model of a message as a simple string accompanied by arguments, with "method call"-like semantics adequate?
  • If you could use PLASTIC, but it doesn't do enough for you, what is missing?
  • If PLASTIC were replaced by something else, what features of PLASTIC do you like and would like to retain?
Comment

Beyond the desktop

Inter-application messaging will typically be only on a single machine, however there may be cases where a general application messaging system might involve more than one computer. For instance, a remote compute cluster pushing data to a desktop app for visualization, a server process providing access to a remote resource, etc

Desktop2Desktop

  • Is there a demand for collaborative data exploration?
  • What technologies are there that could facilitate this, and cope with firewalls, NATS etc?
Comment

Desktop2Server

  • Is this any of our business or is this a GWS issue?
Comment

And finally...

  • The term 'Applications' should not be limited to the current suite of desktop tools, we should consider any application one might imagine
  • What should our target be for May?
Comment

-- JohnTaylor & MikeFitzpatrick - 07 Feb 2007

Revision 82007-02-09 - BrunoRino

 
META TOPICPARENT name="ApplicationsMessaging"

<--  
-->

Applications Messaging - Initial Questions for the Community

To spark off the discussion of what we want from an Applications Messaging System, we've prepared some questions and topics for discussion. If you have opinions on these issues, then please add your views to the appropriate page. Following this we'll try to distill people's views into some sort of consensus (if possible!), considering what is achievable in the time we have.

Questions to kick off the IVOA Applications Messaging discussion

General Questions

Comment

There is a general acceptance that message infrastructure and messaging syntax&semantics should be treated separately:

Infrastructure

  • Which set of platforms/languages should be able to access the messaging system? Comment
  • Do we need....?
    • Security?
      • How much?
    • Encryption?
    • Guaranteed delivery?
    • Guaranteed ordering?
    • Queuing of messages?
    • Transactions?
Comment
  • Everything changes: how do we deal with versioning of the protocol? Comment
  • Should the system be dynamic (apps discover each other at runtime), or static (apps can be discovered even when not running?)
    • Is there/should there be a mechanism to start non-running apps?
Comment
  • How do applications discover each other's capabilities?
    • Dynamically?
    • Through the registry?
    • Statically for apps they already "know"
Comment

Messages

  • Who should define messages? Comment
  • What should be the format of a message? Comment
  • What are the message categories? Comment
  • 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? Comment
  • 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? Comment
  • Do we need to be concerned with obsolescence of messages? Comment
  • In a Hub-based architecture, should the hub have any concept of the meaning of messages? Comment

Data Transport

  • What data formats should we use?
  • Do we need to send a data subset (i.e. rows from a table or image ROI only)?
  • Do we need to share access to data (rather than passing references and each app making a copy)?
Comment

Intradesktop Messaging Questions

General

  • Is a hub-based architecture best or should it be peer to peer or something else?
  • Do we need to be able to partition apps within a hub into separate mutually inaccessible groups?
  • Do we want a request-reponse style messaging?
    • Asynchronous messaging?
    • Polling?
Comment

PLASTIC-specific Questions

The following questions are to gauge how suitable PLASTIC is as a foundation for the restricted case of intradesktop application messaging:

Compatibility

  • Can your application send and receive messages via PLASTIC?
    • If not, why not?
  • Could you embed a PLASTIC Hub in your application?
    • If not, what's stopping you?

Ease of use

  • Should PLASTIC have more underlying transport protocols?
  • Should PLASTIC have fewer underlying transport protocols?
  • What would you change in the PLASTIC API?
  • How do we deal with a multi Hub world?
    • Do we need a protocol for "handover" as one hub shuts down?

Power

  • Is the PLASTIC model of a message as a simple string accompanied by arguments, with "method call"-like semantics adequate?
  • If you could use PLASTIC, but it doesn't do enough for you, what is missing?
  • If PLASTIC were replaced by something else, what features of PLASTIC do you like and would like to retain?
Comment

Beyond the desktop

Inter-application messaging will typically be only on a single machine, however there may be cases where a general application messaging system might involve more than one computer. For instance, a remote compute cluster pushing data to a desktop app for visualization, a server process providing access to a remote resource, etc

Desktop2Desktop

  • Is there a demand for collaborative data exploration?
  • What technologies are there that could facilitate this, and cope with firewalls, NATS etc?
Comment

Desktop2Server

  • Is this any of our business or is this a GWS issue?
Comment

And finally...

  • The term 'Applications' should not be limited to the current suite of desktop tools, we should consider any application one might imagine
  • What should our target be for May?
Comment
Changed:
<
<
-- JohnTaylor & MikeFitzpatrick - 07 Feb 2007
>
>
-- JohnTaylor & MikeFitzpatrick - 07 Feb 2007
 

Revision 72007-02-08 - JohnTaylor

 
META TOPICPARENT name="ApplicationsMessaging"
Deleted:
<
<
 
<--  
-->

Applications Messaging - Initial Questions for the Community

To spark off the discussion of what we want from an Applications Messaging System, we've prepared some questions and topics for discussion. If you have opinions on these issues, then please add your views to the appropriate page. Following this we'll try to distill people's views into some sort of consensus (if possible!), considering what is achievable in the time we have.

Questions to kick off the IVOA Applications Messaging discussion

General Questions

Comment

There is a general acceptance that message infrastructure and messaging syntax&semantics should be treated separately:

Infrastructure

  • Which set of platforms/languages should be able to access the messaging system? Comment
  • Do we need....?
    • Security?
      • How much?
    • Encryption?
    • Guaranteed delivery?
    • Guaranteed ordering?
    • Queuing of messages?
    • Transactions?
Comment
  • Everything changes: how do we deal with versioning of the protocol? Comment
  • Should the system be dynamic (apps discover each other at runtime), or static (apps can be discovered even when not running?)
    • Is there/should there be a mechanism to start non-running apps?
Comment
  • How do applications discover each other's capabilities?
    • Dynamically?
    • Through the registry?
    • Statically for apps they already "know"
Comment

Messages

  • Who should define messages? Comment
  • What should be the format of a message? Comment
  • What are the message categories? Comment
  • 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? Comment
  • 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? Comment
  • Do we need to be concerned with obsolescence of messages? Comment
  • In a Hub-based architecture, should the hub have any concept of the meaning of messages? Comment

Data Transport

  • What data formats should we use?
  • Do we need to send a data subset (i.e. rows from a table or image ROI only)?
  • Do we need to share access to data (rather than passing references and each app making a copy)?
Comment

Intradesktop Messaging Questions

General

  • Is a hub-based architecture best or should it be peer to peer or something else?
  • Do we need to be able to partition apps within a hub into separate mutually inaccessible groups?
  • Do we want a request-reponse style messaging?
    • Asynchronous messaging?
    • Polling?
Comment

PLASTIC-specific Questions

The following questions are to gauge how suitable PLASTIC is as a foundation for the restricted case of intradesktop application messaging:

Compatibility

  • Can your application send and receive messages via PLASTIC?
    • If not, why not?
  • Could you embed a PLASTIC Hub in your application?
    • If not, what's stopping you?

Ease of use

  • Should PLASTIC have more underlying transport protocols?
Deleted:
<
<
(e.g. UDP broadcasting, JMS, http-get)
 
  • Should PLASTIC have fewer underlying transport protocols?
  • What would you change in the PLASTIC API?
  • How do we deal with a multi Hub world?
    • Do we need a protocol for "handover" as one hub shuts down?

Power

  • Is the PLASTIC model of a message as a simple string accompanied by arguments, with "method call"-like semantics adequate?
  • If you could use PLASTIC, but it doesn't do enough for you, what is missing?
  • If PLASTIC were replaced by something else, what features of PLASTIC do you like and would like to retain?
Comment

Beyond the desktop

Inter-application messaging will typically be only on a single machine, however there may be cases where a general application messaging system might involve more than one computer. For instance, a remote compute cluster pushing data to a desktop app for visualization, a server process providing access to a remote resource, etc
Changed:
<
<

Client2Client

>
>

Desktop2Desktop

 
  • Is there a demand for collaborative data exploration?
  • What technologies are there that could facilitate this, and cope with firewalls, NATS etc?
Comment
Changed:
<
<

Client2Server

>
>

Desktop2Server

 
  • Is this any of our business or is this a GWS issue?
Changed:
<
<
Comment
>
>
Comment
 

And finally...

  • The term 'Applications' should not be limited to the current suite of desktop tools, we should consider any application one might imagine
  • What should our target be for May?
Changed:
<
<
Comment
>
>
Comment
  -- JohnTaylor & MikeFitzpatrick - 07 Feb 2007

Revision 62007-02-08 - JohnTaylor

 
META TOPICPARENT name="ApplicationsMessaging"

Deleted:
<
<
 
<--  
-->

Applications Messaging - Initial Questions for the Community

To spark off the discussion of what we want from an Applications Messaging System, we've prepared some questions and topics for discussion. If you have opinions on these issues, then please add your views to the appropriate page. Following this we'll try to distill people's views into some sort of consensus (if possible!), considering what is achievable in the time we have.

Questions to kick off the IVOA Applications Messaging discussion

General Questions

Comment

There is a general acceptance that message infrastructure and messaging syntax&semantics should be treated separately:

Infrastructure

  • Which set of platforms/languages should be able to access the messaging system? Comment
  • Do we need....?
    • Security?
      • How much?
    • Encryption?
    • Guaranteed delivery?
    • Guaranteed ordering?
    • Queuing of messages?
    • Transactions?
Comment
  • Everything changes: how do we deal with versioning of the protocol? Comment
  • Should the system be dynamic (apps discover each other at runtime), or static (apps can be discovered even when not running?)
    • Is there/should there be a mechanism to start non-running apps?
Comment
  • How do applications discover each other's capabilities?
    • Dynamically?
    • Through the registry?
    • Statically for apps they already "know"
Comment

Messages

  • Who should define messages? Comment
  • What should be the format of a message? Comment
Changed:
<
<
(move following) string? ivorn? xml?
>
>
  • What are the message categories? Comment
Deleted:
<
<
  • What are the message categories?
(move following) Administrative (e.g. app (dis)connected) Image Operations (e.g. loadImage) Table Operations (e.g. loadTable) Procedure calls Status/Info Get/Set methods [[ApplicationsMessagingInitialQuestions][Nine][Comment]]
 
  • 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? Comment
  • 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? Comment
  • Do we need to be concerned with obsolescence of messages? Comment
  • In a Hub-based architecture, should the hub have any concept of the meaning of messages? Comment

Data Transport

  • What data formats should we use?
  • Do we need to send a data subset (i.e. rows from a table or image ROI only)?
  • Do we need to share access to data (rather than passing references and each app making a copy)?
Comment

Intradesktop Messaging Questions

General

  • Is a hub-based architecture best or should it be peer to peer or something else?
  • Do we need to be able to partition apps within a hub into separate mutually inaccessible groups?
  • Do we want a request-reponse style messaging?
    • Asynchronous messaging?
    • Polling?
Comment

PLASTIC-specific Questions

The following questions are to gauge how suitable PLASTIC is as a foundation for the restricted case of intradesktop application messaging:

Compatibility

  • Can your application send and receive messages via PLASTIC?
    • If not, why not?
  • Could you embed a PLASTIC Hub in your application?
    • If not, what's stopping you?

Ease of use

  • Should PLASTIC have more underlying transport protocols?
(e.g. UDP broadcasting, JMS, http-get)
  • Should PLASTIC have fewer underlying transport protocols?
  • What would you change in the PLASTIC API?
  • How do we deal with a multi Hub world?
    • Do we need a protocol for "handover" as one hub shuts down?

Power

  • Is the PLASTIC model of a message as a simple string accompanied by arguments, with "method call"-like semantics adequate?
  • If you could use PLASTIC, but it doesn't do enough for you, what is missing?
  • If PLASTIC were replaced by something else, what features of PLASTIC do you like and would like to retain?
Comment

Beyond the desktop

Inter-application messaging will typically be only on a single machine, however there may be cases where a general application messaging system might involve more than one computer. For instance, a remote compute cluster pushing data to a desktop app for visualization, a server process providing access to a remote resource, etc

Client2Client

  • Is there a demand for collaborative data exploration?
  • What technologies are there that could facilitate this, and cope with firewalls, NATS etc?
Comment

Client2Server

  • Is this any of our business or is this a GWS issue?
Comment

And finally...

  • The term 'Applications' should not be limited to the current suite of desktop tools, we should consider any application one might imagine
  • What should our target be for May?
Comment

-- JohnTaylor & MikeFitzpatrick - 07 Feb 2007

Revision 52007-02-08 - JohnTaylor

 
META TOPICPARENT name="ApplicationsMessaging"

Deleted:
<
<
 
<--  
-->

Applications Messaging - Initial Questions for the Community

To spark off the discussion of what we want from an Applications Messaging System, we've prepared some questions and topics for discussion. If you have opinions on these issues, then please add your views to the appropriate page. Following this we'll try to distill people's views into some sort of consensus (if possible!), considering what is achievable in the time we have.

Questions to kick off the IVOA Applications Messaging discussion

General Questions

Added:
>
>
Comment
  There is a general acceptance that message infrastructure and messaging syntax&semantics should be treated separately:

Infrastructure

Changed:
<
<
  • Which set of platforms/languages should be able to access the messaging system?
>
>
  • Which set of platforms/languages should be able to access the messaging system? Comment
 
  • Do we need....?
    • Security?
      • How much?
    • Encryption?
    • Guaranteed delivery?
    • Guaranteed ordering?
    • Queuing of messages?
    • Transactions?
Changed:
<
<
  • Everything changes: how do we deal with versioning of the protocol?
>
>
Comment
Added:
>
>
  • Everything changes: how do we deal with versioning of the protocol? Comment
 
  • Should the system be dynamic (apps discover each other at runtime), or static (apps can be discovered even when not running?)
    • Is there/should there be a mechanism to start non-running apps?
Added:
>
>
Comment
 
  • How do applications discover each other's capabilities?
    • Dynamically?
    • Through the registry?
    • Statically for apps they already "know"
Added:
>
>
Comment
 

Messages

Changed:
<
<
  • Who should define messages?
  • What should be the format of a message?
>
>
  • Who should define messages? Comment
  • What should be the format of a message? Comment
 (move following) string? ivorn? xml?
  • What are the message categories?
(move following) Administrative (e.g. app (dis)connected) Image Operations (e.g. loadImage) Table Operations (e.g. loadTable) Procedure calls Status/Info Get/Set methods
Changed:
<
<
  • 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?
  • 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?
  • Do we need to be concerned with obsolescence of messages?
  • In a Hub-based architecture, should the hub have any concept of the meaning of messages?
>
>
[[ApplicationsMessagingInitialQuestions][Nine][Comment]]
  • 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? Comment
  • 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? Comment
  • Do we need to be concerned with obsolescence of messages? Comment
Added:
>
>
  • In a Hub-based architecture, should the hub have any concept of the meaning of messages? Comment
 

Data Transport

  • What data formats should we use?
  • Do we need to send a data subset (i.e. rows from a table or image ROI only)?
  • Do we need to share access to data (rather than passing references and each app making a copy)?
Changed:
<
<
    • How?
>
>
Comment
 

Intradesktop Messaging Questions

General

  • Is a hub-based architecture best or should it be peer to peer or something else?
  • Do we need to be able to partition apps within a hub into separate mutually inaccessible groups?
  • Do we want a request-reponse style messaging?
    • Asynchronous messaging?
    • Polling?
Added:
>
>
Comment
 

PLASTIC-specific Questions

The following questions are to gauge how suitable PLASTIC is as a foundation for the restricted case of intradesktop application messaging:

Compatibility

  • Can your application send and receive messages via PLASTIC?
    • If not, why not?
  • Could you embed a PLASTIC Hub in your application?
    • If not, what's stopping you?

Ease of use

  • Should PLASTIC have more underlying transport protocols?
(e.g. UDP broadcasting, JMS, http-get)
  • Should PLASTIC have fewer underlying transport protocols?
  • What would you change in the PLASTIC API?
  • How do we deal with a multi Hub world?
    • Do we need a protocol for "handover" as one hub shuts down?

Power

  • Is the PLASTIC model of a message as a simple string accompanied by arguments, with "method call"-like semantics adequate?
  • If you could use PLASTIC, but it doesn't do enough for you, what is missing?
  • If PLASTIC were replaced by something else, what features of PLASTIC do you like and would like to retain?
Added:
>
>
Comment
 
Deleted:
<
<
 

Beyond the desktop

Inter-application messaging will typically be only on a single machine, however there may be cases where a general application messaging system might involve more than one computer. For instance, a remote compute cluster pushing data to a desktop app for visualization, a server process providing access to a remote resource, etc

Client2Client

  • Is there a demand for collaborative data exploration?
  • What technologies are there that could facilitate this, and cope with firewalls, NATS etc?
Added:
>
>
Comment
 

Client2Server

  • Is this any of our business or is this a GWS issue?
Added:
>
>
Comment
 
Deleted:
<
<
 

And finally...

  • The term 'Applications' should not be limited to the current suite of desktop tools, we should consider any application one might imagine
  • What should our target be for May?
Added:
>
>
Comment
 
Changed:
<
<
>
>
-- JohnTaylor & MikeFitzpatrick - 07 Feb 2007
Deleted:
<
<
-- JohnTaylor - 01 Feb 2007
 

Revision 42007-02-07 - JohnTaylor

 
META TOPICPARENT name="ApplicationsMessaging"

Deleted:
<
<
 
<--  
-->

Applications Messaging - Initial Questions for the Community

To spark off the discussion of what we want from an Applications Messaging System, we've prepared some questions and topics for discussion. If you have opinions on these issues, then please add your views to the appropriate page. Following this we'll try to distill people's views into some sort of consensus (if possible!), considering what is achievable in the time we have.

Questions to kick off the IVOA Applications Messaging discussion

General Questions

There is a general acceptance that message infrastructure and messaging syntax&semantics should be treated separately:

Infrastructure

  • Which set of platforms/languages should be able to access the messaging system?
  • Do we need....?
    • Security?
      • How much?
    • Encryption?
    • Guaranteed delivery?
    • Guaranteed ordering?
    • Queuing of messages?
    • Transactions?
  • Everything changes: how do we deal with versioning of the protocol?
  • Should the system be dynamic (apps discover each other at runtime), or static (apps can be discovered even when not running?)
    • Is there/should there be a mechanism to start non-running apps?
Added:
>
>
  • How do applications discover each other's capabilities?
    • Dynamically?
    • Through the registry?
    • Statically for apps they already "know"
 

Messages

  • Who should define messages?
Added:
>
>
  • What should be the format of a message?
(move following) string? ivorn? xml?
 
  • What are the message categories?
(move following) Administrative (e.g. app (dis)connected) Image Operations (e.g. loadImage) Table Operations (e.g. loadTable) Procedure calls Status/Info Get/Set methods
  • 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?
Added:
>
>
  • 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?
 
  • Do we need to be concerned with obsolescence of messages?
  • In a Hub-based architecture, should the hub have any concept of the meaning of messages?
Changed:
<
<
  • Do we need to share access to data (rather than passing references and each app making a copy)?
>
>
Added:
>
>

Data Transport

  • What data formats should we use?
  • Do we need to send a data subset (i.e. rows from a table or image ROI only)?
  • Do we need to share access to data (rather than passing references and each app making a copy)?
 
    • How?
Changed:
<
<
>
>

Intradesktop Messaging Questions

Deleted:
<
<

Intradesktop messaging Questions

 

General

Changed:
<
<
  • Is a hub-based architecture best or should it be peer to peer?
>
>
  • Is a hub-based architecture best or should it be peer to peer or something else?
Added:
>
>
  • Do we need to be able to partition apps within a hub into separate mutually inaccessible groups?
 
  • Do we want a request-reponse style messaging?
Changed:
<
<
  • Asynchronous messaging?
  • Polling?
>
>
    • Asynchronous messaging?
    • Polling?
 

PLASTIC-specific Questions

The following questions are to gauge how suitable PLASTIC is as a foundation for the restricted case of intradesktop application messaging:
Changed:
<
<

Compatibility

>
>

Compatibility

 
  • Can your application send and receive messages via PLASTIC?
Changed:
<
<
    • If not, what is missing?
>
>
    • If not, why not?
 
  • Could you embed a PLASTIC Hub in your application?
    • If not, what's stopping you?
Changed:
<
<

Ease of use

>
>

Ease of use

 
  • Should PLASTIC have more underlying transport protocols?
Added:
>
>
(e.g. UDP broadcasting, JMS, http-get)
 
  • Should PLASTIC have fewer underlying transport protocols?
  • What would you change in the PLASTIC API?
  • How do we deal with a multi Hub world?
    • Do we need a protocol for "handover" as one hub shuts down?

Power

  • Is the PLASTIC model of a message as a simple string accompanied by arguments, with "method call"-like semantics adequate?
Changed:
<
<
  • Can PLASTIC cope with the widely different capabilities of different applications?
>
>
  • If you could use PLASTIC, but it doesn't do enough for you, what is missing?
 
  • If PLASTIC were replaced by something else, what features of PLASTIC do you like and would like to retain?

Beyond the desktop

Inter-application messaging will typically be only on a single machine, however there may be cases where a general application messaging system might involve more than one computer. For instance, a remote compute cluster pushing data to a desktop app for visualization, a server process providing access to a remote resource, etc

Client2Client

  • Is there a demand for collaborative data exploration?
  • What technologies are there that could facilitate this, and cope with firewalls, NATS etc?

Client2Server

  • Is this any of our business or is this a GWS issue?

And finally...

  • The term 'Applications' should not be limited to the current suite of desktop tools, we should consider any application one might imagine
  • What should our target be for May?

-- JohnTaylor - 01 Feb 2007

Revision 32007-02-07 - JohnTaylor

 
META TOPICPARENT name="ApplicationsMessaging"

Deleted:
<
<
 
<--  
-->

Applications Messaging - Initial Questions for the Community

To spark off the discussion of what we want from an Applications Messaging System, we've prepared some questions and topics for discussion. If you have opinions on these issues, then please add your views to the appropriate page. Following this we'll try to distill people's views into some sort of consensus (if possible!), considering what is achievable in the time we have.

Questions to kick off the IVOA Applications Messaging discussion

General Questions

Added:
>
>

There is a general acceptance that message infrastructure and messaging syntax&semantics should be treated separately:

 

Infrastructure

  • Which set of platforms/languages should be able to access the messaging system?
  • Do we need....?
    • Security?
      • How much?
    • Encryption?
    • Guaranteed delivery?
    • Guaranteed ordering?
    • Queuing of messages?
    • Transactions?
Changed:
<
<
  • Everything changes: How do we deal with versioning of the protocol?
>
>
  • Everything changes: how do we deal with versioning of the protocol?
 
  • Should the system be dynamic (apps discover each other at runtime), or static (apps can be discovered even when not running?)
    • Is there/should there be a mechanism to start non-running apps?

Messages

  • Who should define messages?
Changed:
<
<
  • How do we balance the need for messages to be general enough for max interop, with the specicifity needed to exploit the full power of an app?
>
>
  • What are the message categories?
Added:
>
>
(move following) Administrative (e.g. app (dis)connected) Image Operations (e.g. loadImage) Table Operations (e.g. loadTable) Procedure calls Status/Info Get/Set methods
  • 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?
 
  • Do we need to be concerned with obsolescence of messages?
  • In a Hub-based architecture, should the hub have any concept of the meaning of messages?
  • Do we need to share access to data (rather than passing references and each app making a copy)?
    • How?

Intradesktop messaging Questions

Added:
>
>

General

 
  • Is a hub-based architecture best or should it be peer to peer?
Changed:
<
<
>
>
  • Do we want a request-reponse style messaging?
Added:
>
>
  • Asynchronous messaging?
  • Polling?
 

PLASTIC-specific Questions

Added:
>
>
The following questions are to gauge how suitable PLASTIC is as a foundation for the restricted case of intradesktop application messaging:
 

Compatibility

  • Can your application send and receive messages via PLASTIC?
    • If not, what is missing?
  • Could you embed a PLASTIC Hub in your application?
    • If not, what's stopping you?

Ease of use

  • Should PLASTIC have more underlying transport protocols?
  • Should PLASTIC have fewer underlying transport protocols?
  • What would you change in the PLASTIC API?
  • How do we deal with a multi Hub world?
    • Do we need a protocol for "handover" as one hub shuts down?
Deleted:
<
<
  • PLASTIC supports request-response style and asynchronous messages. Are both styles necessary?
 

Power

Changed:
<
<
* Is the PLASTIC model of a message as a simple string accompanied by arguments, with "method call"-like semantics adequate?
>
>
  • Is the PLASTIC model of a message as a simple string accompanied by arguments, with "method call"-like semantics adequate?
Deleted:
<
<
 
  • Can PLASTIC cope with the widely different capabilities of different applications?
Added:
>
>
  • If PLASTIC were replaced by something else, what features of PLASTIC do you like and would like to retain?
 

Beyond the desktop

Added:
>
>
Inter-application messaging will typically be only on a single machine, however there may be cases where a general application messaging system might involve more than one computer. For instance, a remote compute cluster pushing data to a desktop app for visualization, a server process providing access to a remote resource, etc
 

Client2Client

  • Is there a demand for collaborative data exploration?
  • What technologies are there that could facilitate this, and cope with firewalls, NATS etc?

Client2Server

  • Is this any of our business or is this a GWS issue?

And finally...

Added:
>
>
  • The term 'Applications' should not be limited to the current suite of desktop tools, we should consider any application one might imagine
 
  • What should our target be for May?

-- JohnTaylor - 01 Feb 2007

Revision 22007-02-07 - JohnTaylor

 
META TOPICPARENT name="ApplicationsMessaging"

Deleted:
<
<
 
<--  
-->

Applications Messaging - Initial Questions for the Community

To spark off the discussion of what we want from an Applications Messaging System, we've prepared some questions and topics for discussion. If you have opinions on these issues, then please add your views to the appropriate page. Following this we'll try to distill people's views into some sort of consensus (if possible!), considering what is achievable in the time we have.
Added:
>
>

Questions to kick off the IVOA Applications Messaging discussion

General Questions

Infrastructure

  • Which set of platforms/languages should be able to access the messaging system?
  • Do we need....?
    • Security?
      • How much?
    • Encryption?
    • Guaranteed delivery?
    • Guaranteed ordering?
    • Queuing of messages?
    • Transactions?
  • Everything changes: How do we deal with versioning of the protocol?
  • Should the system be dynamic (apps discover each other at runtime), or static (apps can be discovered even when not running?)
    • Is there/should there be a mechanism to start non-running apps?

Messages

  • Who should define messages?
  • How do we balance the need for messages to be general enough for max interop, with the specicifity needed to exploit the full power of an app?
  • Do we need to be concerned with obsolescence of messages?
  • In a Hub-based architecture, should the hub have any concept of the meaning of messages?
  • Do we need to share access to data (rather than passing references and each app making a copy)?
    • How?

Intradesktop messaging Questions

  • Is a hub-based architecture best or should it be peer to peer?

PLASTIC-specific Questions

Compatibility

  • Can your application send and receive messages via PLASTIC?
    • If not, what is missing?
  • Could you embed a PLASTIC Hub in your application?
    • If not, what's stopping you?

Ease of use

  • Should PLASTIC have more underlying transport protocols?
  • Should PLASTIC have fewer underlying transport protocols?
  • What would you change in the PLASTIC API?
  • How do we deal with a multi Hub world?
    • Do we need a protocol for "handover" as one hub shuts down?
  • PLASTIC supports request-response style and asynchronous messages. Are both styles necessary?

Power

* Is the PLASTIC model of a message as a simple string accompanied by arguments, with "method call"-like semantics adequate?

  • Can PLASTIC cope with the widely different capabilities of different applications?

Beyond the desktop

Client2Client

  • Is there a demand for collaborative data exploration?
  • What technologies are there that could facilitate this, and cope with firewalls, NATS etc?

Client2Server

  • Is this any of our business or is this a GWS issue?

And finally...

  • What should our target be for May?

-- JohnTaylor - 01 Feb 2007

 

Revision 12007-02-07 - JohnTaylor

 
META TOPICPARENT name="ApplicationsMessaging"


<--  
-->

Applications Messaging - Initial Questions for the Community

To spark off the discussion of what we want from an Applications Messaging System, we've prepared some questions and topics for discussion. If you have opinions on these issues, then please add your views to the appropriate page. Following this we'll try to distill people's views into some sort of consensus (if possible!), considering what is achievable in the time we have.
 
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