Roadmap

How are we going to move vvvv.js ahead?

Multi-host exeution

In the future, vvvv.js should be usable under those scenarios:

1. In the browser, as a solution for graphics and animations in web sites and web applications
2. On a server, in a head-less environment. In this case vvvv.js on the server communicates with instances running inside the browsers of users visiting a website.
3. As a stand-alone solution for general purpose visual programming and visualisation, similar to vvvv itself.

What are the requirements for those scenarios?

1. Browser execution

It's already possible. It would be good if we could abstract away differences between browsers a little more, first and foremost the absence of certain APIs should not make the entire loading process fail.

2. Server-side execution

Vvvv.js should be ported to node.js. Therefore, we urgently need an abstraction layer, because many APIs that are part of the window object in the browser are contained in optional node modules or work in an entirely different way on node.js. A move to AMD and requirejs (http://requirejs.org/docs/whyamd.html) is suggested. Also many existing nodes depend on a graphical environment and should not be loaded on a server.

We agree that the same patch should run on the server and the browser side simultaneously. There are currently two possibilities on how to design browser-server communication:

1. One instance of a patch running on the server per browser session. (Inter-patch communication should be possible in this case)
2. One instance of a patch running per v4p-file on the server catering to multiple browser sessions.

It should be possible to use any kind of server such as Apache to serve the rest of a web site and even v4p patches whereas vvvv.js on node.js only executes patches and communicates with the browser over a separate connection (Web Sockets).

Communication between server-side patches and the browser should work in a fashion similar to boygrouping in vvvv. We need a way to deal with latency transparently.

It should be possible to edit patches on the browser and save them to the web server.

Additional nodes should be created that are specific to server-side execution such as file access and database connections.

Network security is a concern!

3. Stand-alone version

A stand-alone version should support all graphical nodes from the browser version as well as nodes from the server version, to allow a maximum of flexibility. Some nodes that are very specific to the browser environment (possibly HTML nodes?) or the server (inter-patch communication) are not needed in the stand-alone version.

There are several suggested platforms for the implementation:

1. Phonegap / Cordova
2. node-webkit
3. Atom Shell

We should carefully evaluate each platform. A maximum of implementation overlap with the browser and server version is desirable.

The road ahead

Clean up

1. Node metadata / name should be moved out of the contructor

Port to requirejs

1. Do it!
2. Add fine-grained requirements for each node

Add abstraction layer

Options: a) add object VVVV.Host and add methods/subobjects to it when a feature has to be wrapped b) add an AMD module for each feature that has to be wrapped

Try to get running as many nodes as possible on each platform without breaking the others

Lot's of debugging ahead!

Implement server-browser communication

...