- A seamless integration between web client and native DDS clients.
Hard to believe… I was the voice out of the choir. The rest of the crowd seamed to believe, or had some obscure interest to believe, that what really mattered was to provide DDS with a W3C WebService API. Yack! The result of this is a Web-Enabled recommended (not yet adopted) OMG specification that actually has nothing to do with the Web (other than with heavy weight old fashioned Web Services). In essence the end result was more a “Web-Disabled” DDS.
So what to do? Well, if you know me, you’ve already guessed. As I did with simd-cxx for the DDS C++ API I’ve created a prototype of what the real Web-DDS technology should be like. After some fun hacking I am happy to unveil dscript.
I’ve posted an intro presentation on slideshare, but I’ll try to summarize the key points of dscript below.
dscript is composed by two elements:
- Server Side (dscript.play): A Router that transparently bridges data between matching DDS entities, e.g. Browser-2-Browser, DDS-2-Browser and Browser-2-DDS
The client side provides a simplified and refined semantics for the DDS entities, for instance dscript reduces the DDS concepts to Topics, DataReaders, DataWriters and QoS — DomainParticipant and Publishers are managed for you.
The API is reactive and considers DataReaders as the source for a stream of data. This data can be handled by the application or bound to a data cache (notice the cache is not part of the DataReader) that provides a higher order function for processing contained data.
The server side minimizes the number of DataReader / DataWriter created to manage the established sessions and deals with entity garbage collection too.
Enough talking, let me show you some code that actually publishes some data:
And here is some code that consumes data: