unifying jMaki's widget-to-widget and widget-to-Server communication

the jMaki widget model allows for two ways of communication: there is in-page communication from one widget to others on the same page and communication in between a widget and the server

the first case of inter-widget-communication makes use of a high level of abstraction by using a publish/subscribe-mechanism to 'topics' and decriptive wireing called 'glue'.

The second case of widget-server communication is quite lowlevel: each widget directly calles it's service-url and directly processes the response. This has the some implications:

1. Scalability: the number of requests against the server increases linear with the number of widgets that have a need to retrieve server-based data. This is not only bad because of the increased usage of server-resources, but it's also bad because the number of concurrent connections a browser is allowed to open to the same server is limited (by specification to the number of two!). So if the number of widgets polling the same server in parallel increases the overall performance might decreases dramatically.
This even more becomes a reall issue if you try to make use of comet-style communication - if more than one widget tries to hold an open connection to the same server the browser would block completely.

2. Complexety: the widget-developer has to explicitly differentiate in between inter-widget and widget-server communication

the drawback is: Since it's the widget-developer that implements both interfaces it cannot be garanteed that both interfaces allow for the same or even simmilar functionallity. (Which imposes unnessesary complexety to the widget-user). And if the widget-developer happens to implement both interfaces to allow for equivalent functionallity it's quite obvious that there's some redundancy in this.

So why not drop the concept of direct linkage of widget to service-url completely and let all data to/from the server go through the topic a widget publishes/subscribes to?

what is required for this:

- establish a standard event-model by defining appropriate standard topic-message formats.

- a controller (implemented as 'headless' widget aka 'jmaki-extension' that acts as a translator in between topic-messages and server-communication.

- a (single) server-service endpoint that receives these messages and distributes them to (respectivly calls) the serverside dynamic components and sends the return-values (if any) back to the client-side controller to send them to the widgets in question by publishing them to the appropriate topics