Beyond that, what if the device has no file system? How do you write an application with super privileges without any idea of what platform you are targeting?

With source code (that is to be compiled), you have a messy set of conditional #ifdef blocks and you generally only target a few platforms like OS X 10.6+ or Windows.

The current HTML5 sandbox already solves these problems. Regarding files, you can save to local key/value storage, local databases, and config (cookies). Of course you cannot specify a specific path, but that concept is not portable.

So you end up needing to build a sandbox for your new language that does the same thing, and...

... you still end up with those two problems. Not every sandbox will be the same (some people will enhance theirs, or leave features out), and new APIs will be slow to be developed.

But you can write to file. I think it's called cookies...

I much rather have the website store everything serverside though, until I actively choose to download it.

The only information from a website that should be stored on my computer automatically should be a session id. And even that should be deleted when I close the browser.

Really, why should cookies even need to exist? I think the browser could just store session ids in memory instead.

Session cookies aren't saved to disk.

I only restart my browser when it breaks down too badly. So I'd only have to log in like once a week or thereabouts.

I searched Firefox and couldn't find any option to only allow storage of session cookie.

I use the CookieSafe to control the lifetimes of my cookies (websites that I trust can place long term cookies... everbody else either gets no cookies at all, or those that get deleted at the end of a session).

These days I find myself using only C#, G-code and RAPID. And the occasional Visual Basic.

Canvas + Javascript is a very inefficient solution. That's why someone earlier said that doing your own font rendering engine is for masochists.

No, my solution is not the same thing at all, because the API the browser would provide would be more lower-level than what it currently has. And a more lower level API would open for more possibilities.

Not if the language is well-defined.

That's what the sandbox is for. The web page you download already affects your computer anyway.

There are no devices that I know of that have no filesystem. Care to show us one?

Why should you need to write a web application with super privileges? that's not part of the discussion we are having anyway.

That concerns C and C++. If you make the downloaded code in C or C++, then you deserve to get that.

But there are other possibilities out there. Even (*gasp*) new programming languages.

My proposal did not introduce those problems anyway.

If you are talking about web storage, that's very limited and inefficient (due to storing strings only), and not yet a standard.

Nope. Not part of the web specification, as far as I know.

>, and config (cookies).

Terrible solution.

A better sandbox that opens new capabilities.

Not if the browser API contains better primitives than it currently supports.

It's not the same to provide, let's say, a text box, and the means to implement said text box. The former is fixed functionality, the latter is not. There is a great difference.

We will see how it goes, and which browsers run it in good speed.

That's valid if all players adopt it. Otherwise, one has to account for the players that have not adopted it yet.

By all means, let's hear your suggestions.

Anyone notice how the op of this thread has not once chimed in...

Maybe deathwish is up to his old ways again.

I've been addicted to Lua for the past 9 months or so.

LuaJIT's ffi bindings and native C callbacks is what really sold it for me. Not to mention that LuaJIT is blazing fast. The argument of "Use Lua, but write performance critical code in C/C++" holds a lot less water these days.

That's the beauty of the ffi bindings. You don't have to write bindings. LuaJIT can call functions directly from a library. All you need to do is let Lua know which library you want to use, and what the function signature is.

local some_defs = "unsigned int My_Long_Ass_C_Function_That_Does_everything( int are_you_awesome );"

ffi.cdef( some_defs )

local my_library = ffi.load( "my_library.dll" or "my_library.so", etc )

print( my_library.My_Long_Ass_C_Function_That_Does_everything( true ) )

Any library out there that's written in C is instantly usable, so long as you provide the header file (i.e., function signatures) to Lua. Imagine the possibilities!

It's not LUA. It's Lua. It's not PERL. It's Perl.