On Wed, 09 Sep 2009 00:36:17 -0700, Anselm R Garbe <garbeam_AT_gmail.com> wrote:
> 2009/9/9 pancake <pancake_AT_youterm.com>:
>> There is also "neko". The problem is that I don't see the need of clientside
>> scripting. A clean design should split presentation and data. And having a
>> templating language for merging them into a canvas. So not having the
>> possibility to create infinite loops, eat the CPU, etc.. The web should be
>> safe and simple. If you want to run something more complex you should use a
>> sandbox or something able to do static code analysis in a way that ensures
>> me that the running code is no dangerous.
>
> Oh, are you saying you found a way to decide the halting problem?
>
No... but there are ways to contain malicious execution.
I think client side scripting is required to avoid round-trips to the server for simple operations (changing views for eg.). Also, once the decision is made on implementing a "full" language, I would _not_ like the base UI abstraction to be declarative (mainly from a minimalism point of view).
As an extreme example I was thinking of running an arbitrary executable downloaded from the "website" and running it in a process which is allowed to do only IPC to its parent process. The parent process controls CPU and memory resources of the client. For everything else the client process does IPC... this includes accessing APIs to render the canvas and access the network. It may be a good idea to settle on a cross-platform bytecode format for the same... there are quite a few to choose from.
It would be really nice if we could make it scripting language independent. People should have a choice to use Lua, Neko, Io or whatever they like to build a "webapp" and access the core runtime (through IPC).
-- PinocchioReceived on Thu Sep 10 2009 - 02:47:10 UTC
This archive was generated by hypermail 2.2.0 : Fri Sep 11 2009 - 14:00:03 UTC