joern.weissenborn at gmail.com
So Jan 12 19:55:58 CET 2014
I see some problems in this implementation. As I see it, multiple plugins
using websockets would both receive all events and respond. This would
confuse possible clients, which would maybe want to talk with only one of
those plugins. Also I might want, e.g. when a client requests something, to
be able to send it to this particular client.
Another thing is, that if one implements a plugin to use websockets, one is
basically writing an API for DeepaMehta, at least in my humble opinion. The
main job of such a plugin is to parse the messages and invoke appropriate
commands and translate events into strings which the websocketplugin can
transmit. If I would now implement another interface plugin, like zeromq
(like I did), I would like to reuse this api. I would defenitly like to do
so without modifing it. Since basically every protocol can go with strings,
an api plugin should be complety agnostic on which protocol it is used.
I have build a basic prototype, where I solve this by providing an
api-service, which an interface plugin like websockets or zmq can consume.
Via this service, an interface plugin can get another service object, the
API, identified by a string (e.g. "com.example.dmapi"). This way, the
interface decides on openening a connection, which api to use (the client
could request a certain api upon handshake). The api themselves are
registered at the service by other plugins, which provide an implementation
of the ApiInterface.class.
I think this could be really nice extension, since it would enable third
party developers to develop custom query languages and filter events, based
on the developers data-model. This would save one much work when he writes
multiple clients in different languages.
If you like the idea, I could explain my scheme in more detail. I also want
to publish something, but right now I only have only a basic
proof-of-concept and my job demands my attention, so this could a while.
2014/1/12 Jörg Richter <jri at deepamehta.de>
> On Jan 7, 2014, at 4:40, Jörg Richter wrote:
> > Next possible step from my side:
> > - Make the dm4-websockets plugin extensible by 3rd party plugin
> developers. That is abstracting the WebSocket server (and the Jetty API)
> away and provide the plugin developer a framework for handling client-side
> and server-side WebSocket messages.
> The dm4-websockets plugin is now extensible by 3rd party plugin
> developers. That is your plugin can rely on the facilities provided by the
> dm4-websockets plugin, which basically are:
> - a WebSocket server running on port 8081, usable by several
> plugins at the same time.
> - a service to let your plugin broadcast messages to WebSocket
> clients (server push).
> - server-side events to let your plugin react upon incoming
> WebSocket messages.
> For illustrative purposes there is a WebSockets example application. It
> performs mainly the example task described before: broadcasting topic
> update events to all connected WebSocket clients.
> So, DM is now ready for server push applications.
> However, it's just the first incarnation. If your plugin needs more
> elaborated WebSocket features don't hesitate and post here.
> deepamehta-devel mailing list
> deepamehta-devel at lists.berlios.de
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
Mehr Informationen über die Mailingliste devel