Difference: ApplicationsMessagingInitialQuestionsFifteen (1 vs. 2)

Revision 22007-02-08 - NoelWinstanley

 
META TOPICPARENT name="ApplicationsMessagingInitialQuestions"

Deleted:
<
<
 
<--  
-->

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?
Added:
>
>
Send only (Workbench - Astroscope, Lookout, Myspace Browser all send). Plan to implement receiving of messages for 'display registry entry','astroscope at this position', etc. -- NoelWinstanley
 

Could you embed a PLASTIC Hub in your application?

If not, why not?
Added:
>
>
got one. -- NoelWinstanley
 

Ease of use

Should PLASTIC have more or fewer underlying transport protocols?

(e.g. UDP broadcasting, JMS, http-get) More protocols would allow greater flexibility for application authors, but make it harder to write or embed hubs.
Added:
>
>
not many more (json over http-get?), but certainly remove RMI -- NoelWinstanley
 

What would you change in the PLASTIC API?


How do we deal with a multi Hub world?

It's apparent that many applications are going to want to embed their own Hub. We might want to consider how one Hub could hand over to another if it is shut down.

Power

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

Added:
>
>

so far, so good -- NoelWinstanley
 

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?

Revision 12007-02-08 - JohnTaylor

 
META TOPICPARENT name="ApplicationsMessagingInitialQuestions"


<--  
-->

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, why not?

Ease of use

Should PLASTIC have more or fewer underlying transport protocols?

(e.g. UDP broadcasting, JMS, http-get) More protocols would allow greater flexibility for application authors, but make it harder to write or embed hubs.

What would you change in the PLASTIC API?


How do we deal with a multi Hub world?

It's apparent that many applications are going to want to embed their own Hub. We might want to consider how one Hub could hand over to another if it is shut 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?

 
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