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?

Edit | Attach | Watch | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r1 - 2007-02-08 - JohnTaylor
 
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