[z33m]

Originally Posted by Yathosho

okay, since i shared that terribly miserable loader prototype, i not only travelled 50km by bike, i also gave webvs a little thought.

1. webvs as a service
the loader is the first demo that relies ln the usage of a server-side language, namely the immensely horrible php scripting language. the script populates the dropdown menu for the presets. would i be fluent in cool languages like python, i wouldn't have taken such matters, while rails wasn't applicable as a quick solution. anyway, clear is on thing: webvs can run online and certain stuff will have to be done dynamically on the server side.

This is definitely a good direction, this is precisely what i meant by the "webvs gallery + editor site". I was hacking around with a little bit of https://www.firebase.com/ to getaway with having to write serverside code, though having a server side backend does sound more robust.

Originally Posted by Yathosho

2. webv as an app
one would want to avoid duplicate work wherever possible. the combination of modern javascript and html5 enables webvs to run on all platforms that provide modern browser technology. since the current version of webvs runs on google chrome only (bizarrly other webkit browsers are not supported), i think it's worth thinking about using nodejs as a platform to deploy webvs on the desktop. this would eliminate the need of a variety of languages and little to no adjustments to let webvs run on the server or locally. that said, i probably should have populated the afforementioned preset dropdown using javascript.

Browser compatibility is a bit rough right now, I'll need to find some time to fix this. I havnt thought about this possibility of running webvs in node. This should be possible theoretically. However state of webgl support in headless browser kits or projects like node-webgl seems limited, need to investigate.

Originally Posted by Yathosho

so far i have enjoyed playing around with the available code, especially to test out what could be done on the frontend. i'm not particularly happy about the use of codemirror, as it seem a bit over the top for a rather simple task. also i'd prefer using real html textareas in the editor. regarding the syntax highlighting, there are several simpler solutions in the form of javascript. also, i'm not too happy about the current state of modules. things should be kept simple and modular, the current demo.js contains both the presets plus some additional code.

demo.js was a small hack that i put together to test/demonstrate the library. I just kept adding some smaller changes to it. Never meant it to be used as a real editor, IMO its rather cumbersome to edit avs expressions inside the JSON since they are quoted as strings.

Originally Posted by Yathosho

what are your plans for webvs' future regarding the scale of avs-compatibility and how do judge the level of accuracy? what are your plans regarding web platform and desktop deployment?

I am trying to build components one by one, eventually i hope we'll get to a point where a good number of presets can be supported. As for accuracy, results look pretty good so far, There are a lots of issues and loose ends, like eg. the color of unconed's silk string preset is somewhat messed up, the movement is very shaky compared to AVS and so on.

Originally Posted by Yathosho

i think i will rebuild the frontend from ground up, replacing the editor library with something simpler, then add support to load (and later save) presets. i will then think about how to run server-side code on the nodejs platform. (did i mentioned how extremely well nodejs performs multithreaded?)

for the future, i could see some great ways to integrate music playback. besides soundcloud, other audio and video platforms should be integrated, interacting with all the user features (favourites, libary) that platform offers. needless to say, local music playback should be supported as well, again including library capability and favourites from popular players.

z33m: you started a fire!

Originally Posted by Yathosho

and one more idea:

so far the code is mostly clean and modular (apart from demo.js), so i think if somebody doesn't agree with my ideas for the ui (or simply prefers the classic avs editor approach qoal has taken), the ui part should be kept just as simple as the rest of the plugin. users should be able to install and select a various frontend themes. the webvs core should make it easy for such third party addons to use a variety of libraries (in a similar way jsfiddle offers jquery, mootools etc.). syntax highlighting should be optional from the frontend decisions (though a theme could override that), providing a variety of userstyles in a seperate library. most of the javascript highlighting solutions i prefer over the current editor (i.e. enlighter, highlight.js etc.) already support a variety of highlighting themes.

I agree with this, any larger UI/Frontend work is big project in itself with lots of dependencies, it is nicer to keep the webvs core library simple.