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?

---

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?

---

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.

---

not many more (json over http-get?), but certainly remove RMI -- NoelWinstanley

---

only one transport protocols should be enough; just keep it simple. -- BrunoRino

---

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.

---

What if the last application with embedded hub shuts down? No more PLASTIC Therein lies the case for having a P2P protocol instead of an hub -- BrunoRino

---

Power

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

---

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?